+ All Categories
Home > Documents > Bachelor-Thesis_Julian_Suleder_181348.pdf

Bachelor-Thesis_Julian_Suleder_181348.pdf

Date post: 05-Feb-2017
Category:
Upload: buikhanh
View: 222 times
Download: 0 times
Share this document with a friend
58
Entwicklung einer mobilen Anwendung zur Registrierung von NFC-Tags für die Identifizierung von Personen Bachelor-Thesis zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Medizinische Informatik vorgelegt von Julian Suleder 27. Juli 2015 Referent: Prof. Dr.-Ing. Daniel Pfeifer Korreferent: Prof. Dr. Martin Haag Betreuer: Dipl.-Inform. Med. Peter Rohn
Transcript
Page 1: Bachelor-Thesis_Julian_Suleder_181348.pdf

Entwicklung einer mobilen Anwendung zurRegistrierung von NFC-Tags fuumlr die

Identifizierung von Personen

Bachelor-Thesis

zur Erlangung des akademischen GradesBachelor of Science (BSc) im Studiengang

Medizinische Informatik

vorgelegt von

Julian Suleder

27 Juli 2015

Referent Prof Dr-Ing Daniel Pfeifer

Korreferent Prof Dr Martin Haag

Betreuer Dipl-Inform Med Peter Rohn

Zusammenfassung

Die Identifizierung von Angehoumlrigen der Hochschule Heilbronn erfolgt in der Regeluumlber die Kombination aus Benutzername und Passwort In verschiedenen Einsatzge-bieten wie zB an einer Parkschranke ist eine Eingabe der Benutzermerkmale nichtmoumlglich oder hinderlich Hierfuumlr soll die Mensakarte des Studentenwerks Heidelbergals identifizierendes Merkmal erschlossen werden Dies macht die Verknuumlpfung vonBenutzerkonto und Karte notwendig

Im Rahmen dieser Bachelorarbeit werden zunaumlchst verschiedene Umsetzungsmoumlglich-keiten fuumlr mobile Anwendungen zur Verknuumlpfung von Benutzer und Karte unter Ver-wendung der NFC-Technologie analysiert und ausgewertet Anschlieszligend wird einfunktionaler Prototyp fuumlr Smartphones der Android -Plattform entwickelt der die ein-fache Einbindung weiterer Funktionalitaumlt ermoumlglichen soll

Der entwickelte Prototyp ist im Hochschulnetz testweise fuumlr die Registrierung undDeregistrierung von NFC-Karten einsetzbar Vor einer realen Nutzung des Systemsmuumlssen der Datenschutz und andere organisatorische und rechtliche Pflichten wiezum Beispiel das Telemediengesetz beruumlcksichtigt werden

Danksagung

An dieser Stelle moumlchte ich mich bei meinem Referenten Herrn Prof Dr Daniel Pfeiferfuumlr die engagierte Betreuung und die vielen hilfreichen Gespraumlche bedanken

Ein weiterer Dank geht an Herrn Peter Rohn fuumlr das Feedback und die Motivationwaumlhrend der Bearbeitung des Themas

Fuumlr die Bereitstellung von Server-Infrastruktur und dabei geleistete technische Unter-stuumltzung moumlchte ich den Administratoren der Medizinischen Informatik und speziellHerrn Daniel Zsebedits danken

Dank gilt weiterhin allen Personen die mich bei dieser Arbeit unterstuumltzt oder waumlh-rend des Studiums begleitet haben

Inhaltsverzeichnis

Abkuumlrzungsverzeichnis viii

1 Einleitung 111 Motivation 112 Ziele 113 Vorgehensweise und Struktur der Arbeit 1

2 Grundlagen 221 NFC - Near Field Communication 222 REST - Representional State Transfer 223 JAX-RS - Java API for RESTful Web Services 324 Hybride Applikationen 425 Sicherheitsprobleme hybrider Applikationen 426 Middleware-Frameworks 5

261 AngularJS 5262 Apache Cordova Phonegap 6263 Appcelerator 6264 FireMonkey 6265 Intel XDK 7266 NativeScript 7267 Sencha Touch 7268 TriggerIO 7269 Xamarin 7

27 UI-Frameworks 7271 AppGyver 8272 Famous 8273 Ionic Framework 8274 jQuery Mobile 8275 Kendo UI 8276 Onsen UI 8

28 REST-Frameworks 9281 Apache CXF 9282 Jersey 9283 RESTEasy 9284 Restlet Framework 9

3 Anforderungsanalyse 1031 Kerngedanken der Applikation 1032 Nutzungskontext 1133 Funktionale Anforderungen 11

v

Inhaltsverzeichnis

34 Nichtfunktionale Anforderungen 1235 Initiale Gestaltungsloumlsung 12

351 Papierentwurf der Registrierung 12352 Papierentwurf der Deregistrierung 16

4 Technologieevaluation 1741 Frameworks fuumlr hybride Apps 17

411 Formulierung Muss-Kriterien 17412 Auswertung Muss-Kriterien 18413 Formulierung Soll-Kriterien 19414 Auswertung Soll-Kriterien 20415 Ergebnis 21

42 JAX-RS Implementierungen amp JSON-Umwandlung 22421 Manuelle Umwandlung mit Hilfsklassen 22422 Automatische Umwandlung mit Provider 23423 Automatische Umwandlung uumlber JAXB 24424 Alternativloumlsung mit Servlets 25425 Ergebnis 26

43 Versionierung von App und Server-Backend 26431 URL-Codierung 27432 Media-Type-Codierung 27433 Ergebnis 28

5 Entwurf 2951 Systemarchitektur 2952 Architektur des Server-Backends 3053 Architektur der hybriden App 32

531 Modularisierung und Erweiterbarkeit 32532 Cordova-Plugins 33

54 Kommunikation zwischen App und Server 34

6 Implementierung und Ergebnisse 3561 Prototyp der hybriden App 35

611 Registrierung 35612 Deregistrierung 38613 Allgemeiner Aufbau und andere Inhalte 39

62 Prototyp des Server-Backends 4063 Sicherheitsmechanismen 42

7 Fazit und Ausblick 4371 Diskussion 43

711 Analyse Frameworks fuumlr hybride Applikationen 43

vi

Inhaltsverzeichnis

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung 43713 Entwurf Server-Backend 44714 Funktionaler Prototyp 44715 Modularisierung des Prototyps 44

72 Ausblick 45

8 Literaturverzeichnis 46

Anhang I

A Ionic-Modul Personalverzeichnis II

vii

Abkuumlrzungsverzeichnis

API Application Programming InterfaceCDI Contexts and Dependency InjectionCORS Cross-Origin Resource SharingCSP Content Security PolicyCSS Cascading Style SheetsDTO DatentransferobjektHATEOAS Hypermedia As The Engine Of Application StateHTML HyperText Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentJAXB Java Architecture for XML BindingJAX-RS Java API for RESTful Web ServicesJPA Java Persistence APIJSON JavaScript Object NotationMBaaS Mobile Backend as a ServiceNFC Near Field CommunicationORM ObjectRelational-MapperREST Representional State TransferRFID Radio-Frequency IdentificationRPC Remote Procedure CallSDK Software Development KitSoC Separation of ConcernsSOP Same-Origin PolicyUI User InterfaceURI Uniform Resource IdentifierURL Uniform Resource LocatorXML Extensible Markup LanguageXSRF Cross-Site-Request-ForgeryXSS Cross-Site Scripting

viii

1 Einleitung

11 MotivationIm Zuge des Ausbaus des Bildungscampus am Europaplatz in Heilbronn besteheneingeschraumlnkte Parkmoumlglichkeiten fuumlr Studierende und Mitarbeiter In naher Zukunftwerden neue Parkplaumltze geschaffen die exklusiv fuumlr die genannten Personen nutzbarsein sollen wofuumlr diese identifizierbar sein muumlssen

Die Identifizierung der Personen soll uumlber das Benutzerkonto der Hochschule Heilbronnvorgenommen werden Hierbei kann die Mensakarte des Studentenwerks Heidelberg alsidentifizierendes Merkmal verwendet werden Diese ist noch nicht mit den Benutzer-konten verknuumlpft was nun durchgefuumlhrt werden soll Die Verknuumlpfung soll von jedemBenutzer selbst durchfuumlhrbar sein und keine zusaumltzlichen Anschaffungen wie zB Re-gistrierungsterminals erforderlich machen

Da die Mensakarte die Near Field Communication (NFC)-Technologie unterstuumltztwelche seit geraumer Zeit zB fuumlr das bargeldlose Bezahlen genutzt wird und vieleSmartphones bereits einen NFC-Sensor besitzen soll in dieser Bachelorarbeit einemobile Applikation zur Registrierung dieser NFC-Karten entwickelt werden

12 ZieleDie Ziele dieser Bachelorarbeit sind in der nachfolgenden Aufzaumlhlung erlaumlutert

1 Das Erstellen eines Konzepts fuumlr die Umsetzung einer mobilen Anwendung zurRegistrierung von NFC-Tags und Benutzerkonten Die zu entwickelnde mobileAnwendung soll als hybride App konzipiert sein und fuumlr die Android-Plattformentwickelt werden

2 Die Analyse der verfuumlgbaren Umsetzungsmoumlglichkeiten hybrider Applikationen

3 Die Analyse der Umsetzungsmoumlglichkeiten von REST-Services mit Java-Standards(JAX-RS 20)

4 Die Implementierung eines funktionalen Prototyps des nach 1 entwickelten Kon-zepts mit den nach 2 und 3 ausgewaumlhlten Technologien

13 Vorgehensweise und Struktur der ArbeitZu Beginn der Arbeit wurde eine Anforderungsanalyse durchgefuumlhrt (Kapitel 3) Dieermittelten Anforderungen dienten als Grundlage fuumlr die Analyse und Evaluation ver-fuumlgbarer Technologien (Kapitel 4) mit welchen anschlieszligend ein Entwurf (Kapitel 5)erstellt wurde Dieser wurde in der Folge (Kapitel 6) umgesetzt

1

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 2: Bachelor-Thesis_Julian_Suleder_181348.pdf

Zusammenfassung

Die Identifizierung von Angehoumlrigen der Hochschule Heilbronn erfolgt in der Regeluumlber die Kombination aus Benutzername und Passwort In verschiedenen Einsatzge-bieten wie zB an einer Parkschranke ist eine Eingabe der Benutzermerkmale nichtmoumlglich oder hinderlich Hierfuumlr soll die Mensakarte des Studentenwerks Heidelbergals identifizierendes Merkmal erschlossen werden Dies macht die Verknuumlpfung vonBenutzerkonto und Karte notwendig

Im Rahmen dieser Bachelorarbeit werden zunaumlchst verschiedene Umsetzungsmoumlglich-keiten fuumlr mobile Anwendungen zur Verknuumlpfung von Benutzer und Karte unter Ver-wendung der NFC-Technologie analysiert und ausgewertet Anschlieszligend wird einfunktionaler Prototyp fuumlr Smartphones der Android -Plattform entwickelt der die ein-fache Einbindung weiterer Funktionalitaumlt ermoumlglichen soll

Der entwickelte Prototyp ist im Hochschulnetz testweise fuumlr die Registrierung undDeregistrierung von NFC-Karten einsetzbar Vor einer realen Nutzung des Systemsmuumlssen der Datenschutz und andere organisatorische und rechtliche Pflichten wiezum Beispiel das Telemediengesetz beruumlcksichtigt werden

Danksagung

An dieser Stelle moumlchte ich mich bei meinem Referenten Herrn Prof Dr Daniel Pfeiferfuumlr die engagierte Betreuung und die vielen hilfreichen Gespraumlche bedanken

Ein weiterer Dank geht an Herrn Peter Rohn fuumlr das Feedback und die Motivationwaumlhrend der Bearbeitung des Themas

Fuumlr die Bereitstellung von Server-Infrastruktur und dabei geleistete technische Unter-stuumltzung moumlchte ich den Administratoren der Medizinischen Informatik und speziellHerrn Daniel Zsebedits danken

Dank gilt weiterhin allen Personen die mich bei dieser Arbeit unterstuumltzt oder waumlh-rend des Studiums begleitet haben

Inhaltsverzeichnis

Abkuumlrzungsverzeichnis viii

1 Einleitung 111 Motivation 112 Ziele 113 Vorgehensweise und Struktur der Arbeit 1

2 Grundlagen 221 NFC - Near Field Communication 222 REST - Representional State Transfer 223 JAX-RS - Java API for RESTful Web Services 324 Hybride Applikationen 425 Sicherheitsprobleme hybrider Applikationen 426 Middleware-Frameworks 5

261 AngularJS 5262 Apache Cordova Phonegap 6263 Appcelerator 6264 FireMonkey 6265 Intel XDK 7266 NativeScript 7267 Sencha Touch 7268 TriggerIO 7269 Xamarin 7

27 UI-Frameworks 7271 AppGyver 8272 Famous 8273 Ionic Framework 8274 jQuery Mobile 8275 Kendo UI 8276 Onsen UI 8

28 REST-Frameworks 9281 Apache CXF 9282 Jersey 9283 RESTEasy 9284 Restlet Framework 9

3 Anforderungsanalyse 1031 Kerngedanken der Applikation 1032 Nutzungskontext 1133 Funktionale Anforderungen 11

v

Inhaltsverzeichnis

34 Nichtfunktionale Anforderungen 1235 Initiale Gestaltungsloumlsung 12

351 Papierentwurf der Registrierung 12352 Papierentwurf der Deregistrierung 16

4 Technologieevaluation 1741 Frameworks fuumlr hybride Apps 17

411 Formulierung Muss-Kriterien 17412 Auswertung Muss-Kriterien 18413 Formulierung Soll-Kriterien 19414 Auswertung Soll-Kriterien 20415 Ergebnis 21

42 JAX-RS Implementierungen amp JSON-Umwandlung 22421 Manuelle Umwandlung mit Hilfsklassen 22422 Automatische Umwandlung mit Provider 23423 Automatische Umwandlung uumlber JAXB 24424 Alternativloumlsung mit Servlets 25425 Ergebnis 26

43 Versionierung von App und Server-Backend 26431 URL-Codierung 27432 Media-Type-Codierung 27433 Ergebnis 28

5 Entwurf 2951 Systemarchitektur 2952 Architektur des Server-Backends 3053 Architektur der hybriden App 32

531 Modularisierung und Erweiterbarkeit 32532 Cordova-Plugins 33

54 Kommunikation zwischen App und Server 34

6 Implementierung und Ergebnisse 3561 Prototyp der hybriden App 35

611 Registrierung 35612 Deregistrierung 38613 Allgemeiner Aufbau und andere Inhalte 39

62 Prototyp des Server-Backends 4063 Sicherheitsmechanismen 42

7 Fazit und Ausblick 4371 Diskussion 43

711 Analyse Frameworks fuumlr hybride Applikationen 43

vi

Inhaltsverzeichnis

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung 43713 Entwurf Server-Backend 44714 Funktionaler Prototyp 44715 Modularisierung des Prototyps 44

72 Ausblick 45

8 Literaturverzeichnis 46

Anhang I

A Ionic-Modul Personalverzeichnis II

vii

Abkuumlrzungsverzeichnis

API Application Programming InterfaceCDI Contexts and Dependency InjectionCORS Cross-Origin Resource SharingCSP Content Security PolicyCSS Cascading Style SheetsDTO DatentransferobjektHATEOAS Hypermedia As The Engine Of Application StateHTML HyperText Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentJAXB Java Architecture for XML BindingJAX-RS Java API for RESTful Web ServicesJPA Java Persistence APIJSON JavaScript Object NotationMBaaS Mobile Backend as a ServiceNFC Near Field CommunicationORM ObjectRelational-MapperREST Representional State TransferRFID Radio-Frequency IdentificationRPC Remote Procedure CallSDK Software Development KitSoC Separation of ConcernsSOP Same-Origin PolicyUI User InterfaceURI Uniform Resource IdentifierURL Uniform Resource LocatorXML Extensible Markup LanguageXSRF Cross-Site-Request-ForgeryXSS Cross-Site Scripting

viii

1 Einleitung

11 MotivationIm Zuge des Ausbaus des Bildungscampus am Europaplatz in Heilbronn besteheneingeschraumlnkte Parkmoumlglichkeiten fuumlr Studierende und Mitarbeiter In naher Zukunftwerden neue Parkplaumltze geschaffen die exklusiv fuumlr die genannten Personen nutzbarsein sollen wofuumlr diese identifizierbar sein muumlssen

Die Identifizierung der Personen soll uumlber das Benutzerkonto der Hochschule Heilbronnvorgenommen werden Hierbei kann die Mensakarte des Studentenwerks Heidelberg alsidentifizierendes Merkmal verwendet werden Diese ist noch nicht mit den Benutzer-konten verknuumlpft was nun durchgefuumlhrt werden soll Die Verknuumlpfung soll von jedemBenutzer selbst durchfuumlhrbar sein und keine zusaumltzlichen Anschaffungen wie zB Re-gistrierungsterminals erforderlich machen

Da die Mensakarte die Near Field Communication (NFC)-Technologie unterstuumltztwelche seit geraumer Zeit zB fuumlr das bargeldlose Bezahlen genutzt wird und vieleSmartphones bereits einen NFC-Sensor besitzen soll in dieser Bachelorarbeit einemobile Applikation zur Registrierung dieser NFC-Karten entwickelt werden

12 ZieleDie Ziele dieser Bachelorarbeit sind in der nachfolgenden Aufzaumlhlung erlaumlutert

1 Das Erstellen eines Konzepts fuumlr die Umsetzung einer mobilen Anwendung zurRegistrierung von NFC-Tags und Benutzerkonten Die zu entwickelnde mobileAnwendung soll als hybride App konzipiert sein und fuumlr die Android-Plattformentwickelt werden

2 Die Analyse der verfuumlgbaren Umsetzungsmoumlglichkeiten hybrider Applikationen

3 Die Analyse der Umsetzungsmoumlglichkeiten von REST-Services mit Java-Standards(JAX-RS 20)

4 Die Implementierung eines funktionalen Prototyps des nach 1 entwickelten Kon-zepts mit den nach 2 und 3 ausgewaumlhlten Technologien

13 Vorgehensweise und Struktur der ArbeitZu Beginn der Arbeit wurde eine Anforderungsanalyse durchgefuumlhrt (Kapitel 3) Dieermittelten Anforderungen dienten als Grundlage fuumlr die Analyse und Evaluation ver-fuumlgbarer Technologien (Kapitel 4) mit welchen anschlieszligend ein Entwurf (Kapitel 5)erstellt wurde Dieser wurde in der Folge (Kapitel 6) umgesetzt

1

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 3: Bachelor-Thesis_Julian_Suleder_181348.pdf

Danksagung

An dieser Stelle moumlchte ich mich bei meinem Referenten Herrn Prof Dr Daniel Pfeiferfuumlr die engagierte Betreuung und die vielen hilfreichen Gespraumlche bedanken

Ein weiterer Dank geht an Herrn Peter Rohn fuumlr das Feedback und die Motivationwaumlhrend der Bearbeitung des Themas

Fuumlr die Bereitstellung von Server-Infrastruktur und dabei geleistete technische Unter-stuumltzung moumlchte ich den Administratoren der Medizinischen Informatik und speziellHerrn Daniel Zsebedits danken

Dank gilt weiterhin allen Personen die mich bei dieser Arbeit unterstuumltzt oder waumlh-rend des Studiums begleitet haben

Inhaltsverzeichnis

Abkuumlrzungsverzeichnis viii

1 Einleitung 111 Motivation 112 Ziele 113 Vorgehensweise und Struktur der Arbeit 1

2 Grundlagen 221 NFC - Near Field Communication 222 REST - Representional State Transfer 223 JAX-RS - Java API for RESTful Web Services 324 Hybride Applikationen 425 Sicherheitsprobleme hybrider Applikationen 426 Middleware-Frameworks 5

261 AngularJS 5262 Apache Cordova Phonegap 6263 Appcelerator 6264 FireMonkey 6265 Intel XDK 7266 NativeScript 7267 Sencha Touch 7268 TriggerIO 7269 Xamarin 7

27 UI-Frameworks 7271 AppGyver 8272 Famous 8273 Ionic Framework 8274 jQuery Mobile 8275 Kendo UI 8276 Onsen UI 8

28 REST-Frameworks 9281 Apache CXF 9282 Jersey 9283 RESTEasy 9284 Restlet Framework 9

3 Anforderungsanalyse 1031 Kerngedanken der Applikation 1032 Nutzungskontext 1133 Funktionale Anforderungen 11

v

Inhaltsverzeichnis

34 Nichtfunktionale Anforderungen 1235 Initiale Gestaltungsloumlsung 12

351 Papierentwurf der Registrierung 12352 Papierentwurf der Deregistrierung 16

4 Technologieevaluation 1741 Frameworks fuumlr hybride Apps 17

411 Formulierung Muss-Kriterien 17412 Auswertung Muss-Kriterien 18413 Formulierung Soll-Kriterien 19414 Auswertung Soll-Kriterien 20415 Ergebnis 21

42 JAX-RS Implementierungen amp JSON-Umwandlung 22421 Manuelle Umwandlung mit Hilfsklassen 22422 Automatische Umwandlung mit Provider 23423 Automatische Umwandlung uumlber JAXB 24424 Alternativloumlsung mit Servlets 25425 Ergebnis 26

43 Versionierung von App und Server-Backend 26431 URL-Codierung 27432 Media-Type-Codierung 27433 Ergebnis 28

5 Entwurf 2951 Systemarchitektur 2952 Architektur des Server-Backends 3053 Architektur der hybriden App 32

531 Modularisierung und Erweiterbarkeit 32532 Cordova-Plugins 33

54 Kommunikation zwischen App und Server 34

6 Implementierung und Ergebnisse 3561 Prototyp der hybriden App 35

611 Registrierung 35612 Deregistrierung 38613 Allgemeiner Aufbau und andere Inhalte 39

62 Prototyp des Server-Backends 4063 Sicherheitsmechanismen 42

7 Fazit und Ausblick 4371 Diskussion 43

711 Analyse Frameworks fuumlr hybride Applikationen 43

vi

Inhaltsverzeichnis

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung 43713 Entwurf Server-Backend 44714 Funktionaler Prototyp 44715 Modularisierung des Prototyps 44

72 Ausblick 45

8 Literaturverzeichnis 46

Anhang I

A Ionic-Modul Personalverzeichnis II

vii

Abkuumlrzungsverzeichnis

API Application Programming InterfaceCDI Contexts and Dependency InjectionCORS Cross-Origin Resource SharingCSP Content Security PolicyCSS Cascading Style SheetsDTO DatentransferobjektHATEOAS Hypermedia As The Engine Of Application StateHTML HyperText Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentJAXB Java Architecture for XML BindingJAX-RS Java API for RESTful Web ServicesJPA Java Persistence APIJSON JavaScript Object NotationMBaaS Mobile Backend as a ServiceNFC Near Field CommunicationORM ObjectRelational-MapperREST Representional State TransferRFID Radio-Frequency IdentificationRPC Remote Procedure CallSDK Software Development KitSoC Separation of ConcernsSOP Same-Origin PolicyUI User InterfaceURI Uniform Resource IdentifierURL Uniform Resource LocatorXML Extensible Markup LanguageXSRF Cross-Site-Request-ForgeryXSS Cross-Site Scripting

viii

1 Einleitung

11 MotivationIm Zuge des Ausbaus des Bildungscampus am Europaplatz in Heilbronn besteheneingeschraumlnkte Parkmoumlglichkeiten fuumlr Studierende und Mitarbeiter In naher Zukunftwerden neue Parkplaumltze geschaffen die exklusiv fuumlr die genannten Personen nutzbarsein sollen wofuumlr diese identifizierbar sein muumlssen

Die Identifizierung der Personen soll uumlber das Benutzerkonto der Hochschule Heilbronnvorgenommen werden Hierbei kann die Mensakarte des Studentenwerks Heidelberg alsidentifizierendes Merkmal verwendet werden Diese ist noch nicht mit den Benutzer-konten verknuumlpft was nun durchgefuumlhrt werden soll Die Verknuumlpfung soll von jedemBenutzer selbst durchfuumlhrbar sein und keine zusaumltzlichen Anschaffungen wie zB Re-gistrierungsterminals erforderlich machen

Da die Mensakarte die Near Field Communication (NFC)-Technologie unterstuumltztwelche seit geraumer Zeit zB fuumlr das bargeldlose Bezahlen genutzt wird und vieleSmartphones bereits einen NFC-Sensor besitzen soll in dieser Bachelorarbeit einemobile Applikation zur Registrierung dieser NFC-Karten entwickelt werden

12 ZieleDie Ziele dieser Bachelorarbeit sind in der nachfolgenden Aufzaumlhlung erlaumlutert

1 Das Erstellen eines Konzepts fuumlr die Umsetzung einer mobilen Anwendung zurRegistrierung von NFC-Tags und Benutzerkonten Die zu entwickelnde mobileAnwendung soll als hybride App konzipiert sein und fuumlr die Android-Plattformentwickelt werden

2 Die Analyse der verfuumlgbaren Umsetzungsmoumlglichkeiten hybrider Applikationen

3 Die Analyse der Umsetzungsmoumlglichkeiten von REST-Services mit Java-Standards(JAX-RS 20)

4 Die Implementierung eines funktionalen Prototyps des nach 1 entwickelten Kon-zepts mit den nach 2 und 3 ausgewaumlhlten Technologien

13 Vorgehensweise und Struktur der ArbeitZu Beginn der Arbeit wurde eine Anforderungsanalyse durchgefuumlhrt (Kapitel 3) Dieermittelten Anforderungen dienten als Grundlage fuumlr die Analyse und Evaluation ver-fuumlgbarer Technologien (Kapitel 4) mit welchen anschlieszligend ein Entwurf (Kapitel 5)erstellt wurde Dieser wurde in der Folge (Kapitel 6) umgesetzt

1

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 4: Bachelor-Thesis_Julian_Suleder_181348.pdf

Inhaltsverzeichnis

Abkuumlrzungsverzeichnis viii

1 Einleitung 111 Motivation 112 Ziele 113 Vorgehensweise und Struktur der Arbeit 1

2 Grundlagen 221 NFC - Near Field Communication 222 REST - Representional State Transfer 223 JAX-RS - Java API for RESTful Web Services 324 Hybride Applikationen 425 Sicherheitsprobleme hybrider Applikationen 426 Middleware-Frameworks 5

261 AngularJS 5262 Apache Cordova Phonegap 6263 Appcelerator 6264 FireMonkey 6265 Intel XDK 7266 NativeScript 7267 Sencha Touch 7268 TriggerIO 7269 Xamarin 7

27 UI-Frameworks 7271 AppGyver 8272 Famous 8273 Ionic Framework 8274 jQuery Mobile 8275 Kendo UI 8276 Onsen UI 8

28 REST-Frameworks 9281 Apache CXF 9282 Jersey 9283 RESTEasy 9284 Restlet Framework 9

3 Anforderungsanalyse 1031 Kerngedanken der Applikation 1032 Nutzungskontext 1133 Funktionale Anforderungen 11

v

Inhaltsverzeichnis

34 Nichtfunktionale Anforderungen 1235 Initiale Gestaltungsloumlsung 12

351 Papierentwurf der Registrierung 12352 Papierentwurf der Deregistrierung 16

4 Technologieevaluation 1741 Frameworks fuumlr hybride Apps 17

411 Formulierung Muss-Kriterien 17412 Auswertung Muss-Kriterien 18413 Formulierung Soll-Kriterien 19414 Auswertung Soll-Kriterien 20415 Ergebnis 21

42 JAX-RS Implementierungen amp JSON-Umwandlung 22421 Manuelle Umwandlung mit Hilfsklassen 22422 Automatische Umwandlung mit Provider 23423 Automatische Umwandlung uumlber JAXB 24424 Alternativloumlsung mit Servlets 25425 Ergebnis 26

43 Versionierung von App und Server-Backend 26431 URL-Codierung 27432 Media-Type-Codierung 27433 Ergebnis 28

5 Entwurf 2951 Systemarchitektur 2952 Architektur des Server-Backends 3053 Architektur der hybriden App 32

531 Modularisierung und Erweiterbarkeit 32532 Cordova-Plugins 33

54 Kommunikation zwischen App und Server 34

6 Implementierung und Ergebnisse 3561 Prototyp der hybriden App 35

611 Registrierung 35612 Deregistrierung 38613 Allgemeiner Aufbau und andere Inhalte 39

62 Prototyp des Server-Backends 4063 Sicherheitsmechanismen 42

7 Fazit und Ausblick 4371 Diskussion 43

711 Analyse Frameworks fuumlr hybride Applikationen 43

vi

Inhaltsverzeichnis

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung 43713 Entwurf Server-Backend 44714 Funktionaler Prototyp 44715 Modularisierung des Prototyps 44

72 Ausblick 45

8 Literaturverzeichnis 46

Anhang I

A Ionic-Modul Personalverzeichnis II

vii

Abkuumlrzungsverzeichnis

API Application Programming InterfaceCDI Contexts and Dependency InjectionCORS Cross-Origin Resource SharingCSP Content Security PolicyCSS Cascading Style SheetsDTO DatentransferobjektHATEOAS Hypermedia As The Engine Of Application StateHTML HyperText Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentJAXB Java Architecture for XML BindingJAX-RS Java API for RESTful Web ServicesJPA Java Persistence APIJSON JavaScript Object NotationMBaaS Mobile Backend as a ServiceNFC Near Field CommunicationORM ObjectRelational-MapperREST Representional State TransferRFID Radio-Frequency IdentificationRPC Remote Procedure CallSDK Software Development KitSoC Separation of ConcernsSOP Same-Origin PolicyUI User InterfaceURI Uniform Resource IdentifierURL Uniform Resource LocatorXML Extensible Markup LanguageXSRF Cross-Site-Request-ForgeryXSS Cross-Site Scripting

viii

1 Einleitung

11 MotivationIm Zuge des Ausbaus des Bildungscampus am Europaplatz in Heilbronn besteheneingeschraumlnkte Parkmoumlglichkeiten fuumlr Studierende und Mitarbeiter In naher Zukunftwerden neue Parkplaumltze geschaffen die exklusiv fuumlr die genannten Personen nutzbarsein sollen wofuumlr diese identifizierbar sein muumlssen

Die Identifizierung der Personen soll uumlber das Benutzerkonto der Hochschule Heilbronnvorgenommen werden Hierbei kann die Mensakarte des Studentenwerks Heidelberg alsidentifizierendes Merkmal verwendet werden Diese ist noch nicht mit den Benutzer-konten verknuumlpft was nun durchgefuumlhrt werden soll Die Verknuumlpfung soll von jedemBenutzer selbst durchfuumlhrbar sein und keine zusaumltzlichen Anschaffungen wie zB Re-gistrierungsterminals erforderlich machen

Da die Mensakarte die Near Field Communication (NFC)-Technologie unterstuumltztwelche seit geraumer Zeit zB fuumlr das bargeldlose Bezahlen genutzt wird und vieleSmartphones bereits einen NFC-Sensor besitzen soll in dieser Bachelorarbeit einemobile Applikation zur Registrierung dieser NFC-Karten entwickelt werden

12 ZieleDie Ziele dieser Bachelorarbeit sind in der nachfolgenden Aufzaumlhlung erlaumlutert

1 Das Erstellen eines Konzepts fuumlr die Umsetzung einer mobilen Anwendung zurRegistrierung von NFC-Tags und Benutzerkonten Die zu entwickelnde mobileAnwendung soll als hybride App konzipiert sein und fuumlr die Android-Plattformentwickelt werden

2 Die Analyse der verfuumlgbaren Umsetzungsmoumlglichkeiten hybrider Applikationen

3 Die Analyse der Umsetzungsmoumlglichkeiten von REST-Services mit Java-Standards(JAX-RS 20)

4 Die Implementierung eines funktionalen Prototyps des nach 1 entwickelten Kon-zepts mit den nach 2 und 3 ausgewaumlhlten Technologien

13 Vorgehensweise und Struktur der ArbeitZu Beginn der Arbeit wurde eine Anforderungsanalyse durchgefuumlhrt (Kapitel 3) Dieermittelten Anforderungen dienten als Grundlage fuumlr die Analyse und Evaluation ver-fuumlgbarer Technologien (Kapitel 4) mit welchen anschlieszligend ein Entwurf (Kapitel 5)erstellt wurde Dieser wurde in der Folge (Kapitel 6) umgesetzt

1

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 5: Bachelor-Thesis_Julian_Suleder_181348.pdf

Inhaltsverzeichnis

34 Nichtfunktionale Anforderungen 1235 Initiale Gestaltungsloumlsung 12

351 Papierentwurf der Registrierung 12352 Papierentwurf der Deregistrierung 16

4 Technologieevaluation 1741 Frameworks fuumlr hybride Apps 17

411 Formulierung Muss-Kriterien 17412 Auswertung Muss-Kriterien 18413 Formulierung Soll-Kriterien 19414 Auswertung Soll-Kriterien 20415 Ergebnis 21

42 JAX-RS Implementierungen amp JSON-Umwandlung 22421 Manuelle Umwandlung mit Hilfsklassen 22422 Automatische Umwandlung mit Provider 23423 Automatische Umwandlung uumlber JAXB 24424 Alternativloumlsung mit Servlets 25425 Ergebnis 26

43 Versionierung von App und Server-Backend 26431 URL-Codierung 27432 Media-Type-Codierung 27433 Ergebnis 28

5 Entwurf 2951 Systemarchitektur 2952 Architektur des Server-Backends 3053 Architektur der hybriden App 32

531 Modularisierung und Erweiterbarkeit 32532 Cordova-Plugins 33

54 Kommunikation zwischen App und Server 34

6 Implementierung und Ergebnisse 3561 Prototyp der hybriden App 35

611 Registrierung 35612 Deregistrierung 38613 Allgemeiner Aufbau und andere Inhalte 39

62 Prototyp des Server-Backends 4063 Sicherheitsmechanismen 42

7 Fazit und Ausblick 4371 Diskussion 43

711 Analyse Frameworks fuumlr hybride Applikationen 43

vi

Inhaltsverzeichnis

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung 43713 Entwurf Server-Backend 44714 Funktionaler Prototyp 44715 Modularisierung des Prototyps 44

72 Ausblick 45

8 Literaturverzeichnis 46

Anhang I

A Ionic-Modul Personalverzeichnis II

vii

Abkuumlrzungsverzeichnis

API Application Programming InterfaceCDI Contexts and Dependency InjectionCORS Cross-Origin Resource SharingCSP Content Security PolicyCSS Cascading Style SheetsDTO DatentransferobjektHATEOAS Hypermedia As The Engine Of Application StateHTML HyperText Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentJAXB Java Architecture for XML BindingJAX-RS Java API for RESTful Web ServicesJPA Java Persistence APIJSON JavaScript Object NotationMBaaS Mobile Backend as a ServiceNFC Near Field CommunicationORM ObjectRelational-MapperREST Representional State TransferRFID Radio-Frequency IdentificationRPC Remote Procedure CallSDK Software Development KitSoC Separation of ConcernsSOP Same-Origin PolicyUI User InterfaceURI Uniform Resource IdentifierURL Uniform Resource LocatorXML Extensible Markup LanguageXSRF Cross-Site-Request-ForgeryXSS Cross-Site Scripting

viii

1 Einleitung

11 MotivationIm Zuge des Ausbaus des Bildungscampus am Europaplatz in Heilbronn besteheneingeschraumlnkte Parkmoumlglichkeiten fuumlr Studierende und Mitarbeiter In naher Zukunftwerden neue Parkplaumltze geschaffen die exklusiv fuumlr die genannten Personen nutzbarsein sollen wofuumlr diese identifizierbar sein muumlssen

Die Identifizierung der Personen soll uumlber das Benutzerkonto der Hochschule Heilbronnvorgenommen werden Hierbei kann die Mensakarte des Studentenwerks Heidelberg alsidentifizierendes Merkmal verwendet werden Diese ist noch nicht mit den Benutzer-konten verknuumlpft was nun durchgefuumlhrt werden soll Die Verknuumlpfung soll von jedemBenutzer selbst durchfuumlhrbar sein und keine zusaumltzlichen Anschaffungen wie zB Re-gistrierungsterminals erforderlich machen

Da die Mensakarte die Near Field Communication (NFC)-Technologie unterstuumltztwelche seit geraumer Zeit zB fuumlr das bargeldlose Bezahlen genutzt wird und vieleSmartphones bereits einen NFC-Sensor besitzen soll in dieser Bachelorarbeit einemobile Applikation zur Registrierung dieser NFC-Karten entwickelt werden

12 ZieleDie Ziele dieser Bachelorarbeit sind in der nachfolgenden Aufzaumlhlung erlaumlutert

1 Das Erstellen eines Konzepts fuumlr die Umsetzung einer mobilen Anwendung zurRegistrierung von NFC-Tags und Benutzerkonten Die zu entwickelnde mobileAnwendung soll als hybride App konzipiert sein und fuumlr die Android-Plattformentwickelt werden

2 Die Analyse der verfuumlgbaren Umsetzungsmoumlglichkeiten hybrider Applikationen

3 Die Analyse der Umsetzungsmoumlglichkeiten von REST-Services mit Java-Standards(JAX-RS 20)

4 Die Implementierung eines funktionalen Prototyps des nach 1 entwickelten Kon-zepts mit den nach 2 und 3 ausgewaumlhlten Technologien

13 Vorgehensweise und Struktur der ArbeitZu Beginn der Arbeit wurde eine Anforderungsanalyse durchgefuumlhrt (Kapitel 3) Dieermittelten Anforderungen dienten als Grundlage fuumlr die Analyse und Evaluation ver-fuumlgbarer Technologien (Kapitel 4) mit welchen anschlieszligend ein Entwurf (Kapitel 5)erstellt wurde Dieser wurde in der Folge (Kapitel 6) umgesetzt

1

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 6: Bachelor-Thesis_Julian_Suleder_181348.pdf

Inhaltsverzeichnis

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung 43713 Entwurf Server-Backend 44714 Funktionaler Prototyp 44715 Modularisierung des Prototyps 44

72 Ausblick 45

8 Literaturverzeichnis 46

Anhang I

A Ionic-Modul Personalverzeichnis II

vii

Abkuumlrzungsverzeichnis

API Application Programming InterfaceCDI Contexts and Dependency InjectionCORS Cross-Origin Resource SharingCSP Content Security PolicyCSS Cascading Style SheetsDTO DatentransferobjektHATEOAS Hypermedia As The Engine Of Application StateHTML HyperText Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentJAXB Java Architecture for XML BindingJAX-RS Java API for RESTful Web ServicesJPA Java Persistence APIJSON JavaScript Object NotationMBaaS Mobile Backend as a ServiceNFC Near Field CommunicationORM ObjectRelational-MapperREST Representional State TransferRFID Radio-Frequency IdentificationRPC Remote Procedure CallSDK Software Development KitSoC Separation of ConcernsSOP Same-Origin PolicyUI User InterfaceURI Uniform Resource IdentifierURL Uniform Resource LocatorXML Extensible Markup LanguageXSRF Cross-Site-Request-ForgeryXSS Cross-Site Scripting

viii

1 Einleitung

11 MotivationIm Zuge des Ausbaus des Bildungscampus am Europaplatz in Heilbronn besteheneingeschraumlnkte Parkmoumlglichkeiten fuumlr Studierende und Mitarbeiter In naher Zukunftwerden neue Parkplaumltze geschaffen die exklusiv fuumlr die genannten Personen nutzbarsein sollen wofuumlr diese identifizierbar sein muumlssen

Die Identifizierung der Personen soll uumlber das Benutzerkonto der Hochschule Heilbronnvorgenommen werden Hierbei kann die Mensakarte des Studentenwerks Heidelberg alsidentifizierendes Merkmal verwendet werden Diese ist noch nicht mit den Benutzer-konten verknuumlpft was nun durchgefuumlhrt werden soll Die Verknuumlpfung soll von jedemBenutzer selbst durchfuumlhrbar sein und keine zusaumltzlichen Anschaffungen wie zB Re-gistrierungsterminals erforderlich machen

Da die Mensakarte die Near Field Communication (NFC)-Technologie unterstuumltztwelche seit geraumer Zeit zB fuumlr das bargeldlose Bezahlen genutzt wird und vieleSmartphones bereits einen NFC-Sensor besitzen soll in dieser Bachelorarbeit einemobile Applikation zur Registrierung dieser NFC-Karten entwickelt werden

12 ZieleDie Ziele dieser Bachelorarbeit sind in der nachfolgenden Aufzaumlhlung erlaumlutert

1 Das Erstellen eines Konzepts fuumlr die Umsetzung einer mobilen Anwendung zurRegistrierung von NFC-Tags und Benutzerkonten Die zu entwickelnde mobileAnwendung soll als hybride App konzipiert sein und fuumlr die Android-Plattformentwickelt werden

2 Die Analyse der verfuumlgbaren Umsetzungsmoumlglichkeiten hybrider Applikationen

3 Die Analyse der Umsetzungsmoumlglichkeiten von REST-Services mit Java-Standards(JAX-RS 20)

4 Die Implementierung eines funktionalen Prototyps des nach 1 entwickelten Kon-zepts mit den nach 2 und 3 ausgewaumlhlten Technologien

13 Vorgehensweise und Struktur der ArbeitZu Beginn der Arbeit wurde eine Anforderungsanalyse durchgefuumlhrt (Kapitel 3) Dieermittelten Anforderungen dienten als Grundlage fuumlr die Analyse und Evaluation ver-fuumlgbarer Technologien (Kapitel 4) mit welchen anschlieszligend ein Entwurf (Kapitel 5)erstellt wurde Dieser wurde in der Folge (Kapitel 6) umgesetzt

1

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 7: Bachelor-Thesis_Julian_Suleder_181348.pdf

Abkuumlrzungsverzeichnis

API Application Programming InterfaceCDI Contexts and Dependency InjectionCORS Cross-Origin Resource SharingCSP Content Security PolicyCSS Cascading Style SheetsDTO DatentransferobjektHATEOAS Hypermedia As The Engine Of Application StateHTML HyperText Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentJAXB Java Architecture for XML BindingJAX-RS Java API for RESTful Web ServicesJPA Java Persistence APIJSON JavaScript Object NotationMBaaS Mobile Backend as a ServiceNFC Near Field CommunicationORM ObjectRelational-MapperREST Representional State TransferRFID Radio-Frequency IdentificationRPC Remote Procedure CallSDK Software Development KitSoC Separation of ConcernsSOP Same-Origin PolicyUI User InterfaceURI Uniform Resource IdentifierURL Uniform Resource LocatorXML Extensible Markup LanguageXSRF Cross-Site-Request-ForgeryXSS Cross-Site Scripting

viii

1 Einleitung

11 MotivationIm Zuge des Ausbaus des Bildungscampus am Europaplatz in Heilbronn besteheneingeschraumlnkte Parkmoumlglichkeiten fuumlr Studierende und Mitarbeiter In naher Zukunftwerden neue Parkplaumltze geschaffen die exklusiv fuumlr die genannten Personen nutzbarsein sollen wofuumlr diese identifizierbar sein muumlssen

Die Identifizierung der Personen soll uumlber das Benutzerkonto der Hochschule Heilbronnvorgenommen werden Hierbei kann die Mensakarte des Studentenwerks Heidelberg alsidentifizierendes Merkmal verwendet werden Diese ist noch nicht mit den Benutzer-konten verknuumlpft was nun durchgefuumlhrt werden soll Die Verknuumlpfung soll von jedemBenutzer selbst durchfuumlhrbar sein und keine zusaumltzlichen Anschaffungen wie zB Re-gistrierungsterminals erforderlich machen

Da die Mensakarte die Near Field Communication (NFC)-Technologie unterstuumltztwelche seit geraumer Zeit zB fuumlr das bargeldlose Bezahlen genutzt wird und vieleSmartphones bereits einen NFC-Sensor besitzen soll in dieser Bachelorarbeit einemobile Applikation zur Registrierung dieser NFC-Karten entwickelt werden

12 ZieleDie Ziele dieser Bachelorarbeit sind in der nachfolgenden Aufzaumlhlung erlaumlutert

1 Das Erstellen eines Konzepts fuumlr die Umsetzung einer mobilen Anwendung zurRegistrierung von NFC-Tags und Benutzerkonten Die zu entwickelnde mobileAnwendung soll als hybride App konzipiert sein und fuumlr die Android-Plattformentwickelt werden

2 Die Analyse der verfuumlgbaren Umsetzungsmoumlglichkeiten hybrider Applikationen

3 Die Analyse der Umsetzungsmoumlglichkeiten von REST-Services mit Java-Standards(JAX-RS 20)

4 Die Implementierung eines funktionalen Prototyps des nach 1 entwickelten Kon-zepts mit den nach 2 und 3 ausgewaumlhlten Technologien

13 Vorgehensweise und Struktur der ArbeitZu Beginn der Arbeit wurde eine Anforderungsanalyse durchgefuumlhrt (Kapitel 3) Dieermittelten Anforderungen dienten als Grundlage fuumlr die Analyse und Evaluation ver-fuumlgbarer Technologien (Kapitel 4) mit welchen anschlieszligend ein Entwurf (Kapitel 5)erstellt wurde Dieser wurde in der Folge (Kapitel 6) umgesetzt

1

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 8: Bachelor-Thesis_Julian_Suleder_181348.pdf

1 Einleitung

11 MotivationIm Zuge des Ausbaus des Bildungscampus am Europaplatz in Heilbronn besteheneingeschraumlnkte Parkmoumlglichkeiten fuumlr Studierende und Mitarbeiter In naher Zukunftwerden neue Parkplaumltze geschaffen die exklusiv fuumlr die genannten Personen nutzbarsein sollen wofuumlr diese identifizierbar sein muumlssen

Die Identifizierung der Personen soll uumlber das Benutzerkonto der Hochschule Heilbronnvorgenommen werden Hierbei kann die Mensakarte des Studentenwerks Heidelberg alsidentifizierendes Merkmal verwendet werden Diese ist noch nicht mit den Benutzer-konten verknuumlpft was nun durchgefuumlhrt werden soll Die Verknuumlpfung soll von jedemBenutzer selbst durchfuumlhrbar sein und keine zusaumltzlichen Anschaffungen wie zB Re-gistrierungsterminals erforderlich machen

Da die Mensakarte die Near Field Communication (NFC)-Technologie unterstuumltztwelche seit geraumer Zeit zB fuumlr das bargeldlose Bezahlen genutzt wird und vieleSmartphones bereits einen NFC-Sensor besitzen soll in dieser Bachelorarbeit einemobile Applikation zur Registrierung dieser NFC-Karten entwickelt werden

12 ZieleDie Ziele dieser Bachelorarbeit sind in der nachfolgenden Aufzaumlhlung erlaumlutert

1 Das Erstellen eines Konzepts fuumlr die Umsetzung einer mobilen Anwendung zurRegistrierung von NFC-Tags und Benutzerkonten Die zu entwickelnde mobileAnwendung soll als hybride App konzipiert sein und fuumlr die Android-Plattformentwickelt werden

2 Die Analyse der verfuumlgbaren Umsetzungsmoumlglichkeiten hybrider Applikationen

3 Die Analyse der Umsetzungsmoumlglichkeiten von REST-Services mit Java-Standards(JAX-RS 20)

4 Die Implementierung eines funktionalen Prototyps des nach 1 entwickelten Kon-zepts mit den nach 2 und 3 ausgewaumlhlten Technologien

13 Vorgehensweise und Struktur der ArbeitZu Beginn der Arbeit wurde eine Anforderungsanalyse durchgefuumlhrt (Kapitel 3) Dieermittelten Anforderungen dienten als Grundlage fuumlr die Analyse und Evaluation ver-fuumlgbarer Technologien (Kapitel 4) mit welchen anschlieszligend ein Entwurf (Kapitel 5)erstellt wurde Dieser wurde in der Folge (Kapitel 6) umgesetzt

1

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 9: Bachelor-Thesis_Julian_Suleder_181348.pdf

2 Grundlagen

Dieser Abschnitt stellt die fuumlr die Entwicklung einer hybriden Applikation notwendigenKonzepte und Frameworks zur Realisierung von hybriden Applikationen und REST-Services vor

21 NFC - Near Field CommunicationDie NFC-Technologie ermoumlglicht eine einfache standardisierte [1] und sichere Zwei-Wege-Interaktion zwischen elektronischen Geraumlten sogenannte Tags wodurch die Ver-braucher kontaktlose Transaktionen durchfuumlhren und Zugriff zu digitalen Inhaltenerhalten koumlnnen NFC ergaumlnzt durch die Nutzung bestehender Standards fuumlr kontakt-lose Kartentechnologien1 viele verbrauchernahe Funktechnologien wie zB die Radio-Frequency Identification (RFID) Es vertraumlgt sich mit der bestehenden Infrastrukturfuumlr kontaktlose Karten was die Nutzung eines Geraumlts in verschiedenen Systemen er-moumlglicht Die Uumlbertragungsreichweite betraumlgt maximal 4 Zentimeter [2]

22 REST - Representional State Transfer

Roy Fielding veroumlffentlichte in seiner Doktorarbeit2 eine Sammlung von Architektur-prinzipien fuumlr die Entwicklung verteilter Anwendungen Representional State Trans-fer (REST) ist eine Teilmenge dieser Prinzipien In der Praxis werden die Prinzipienmeist als Beschraumlnkungen an Services mit dem Hypertext Transfer Protocol (HTTP)umgesetzt REST definiert folgende Bedingungen

1 Adressierbarkeit Ein Datensatz wird zu einer Ressource abstrahiert die uumlberihren eindeutigen Uniform Resource Identifier (URI) adressierbar ist [3]

2 Unterschiedliche Repraumlsentationen Eine Ressource kann in verschiedenenFormaten repraumlsentiert werden Je nach Programm wird eine andere Repraumlsen-tation zB in HyperText Markup Language (HTML) oder JavaScript ObjectNotation (JSON) erwartet [3]

3 Zustandslosigkeit Die Kommunikation zwischen Client und Server ist zu-standslos Das bedeutet dass Anfragen alle fuumlr ihre Behandlung noumltigen In-formationen enthalten muumlssen [3]

4 HATEOAS Mit Hypermedia As The Engine Of Application State (HATEOAS)werden Ressourcen in Sammlungen durch deren URI ersetzt und vom Clienteinzeln nachgeladen Zusaumltzlich werden weitere moumlgliche Aktionen in Form vonVerweisen mitgeteilt was zur Vereinfachung von der Client-Logik fuumlhrt [3]

1ISOIEC 14443-Familie Internationale Normenreihe fuumlr kontaktlose Chipkarten2Roy Fielding Architectural Styles and the Design of Network-based Software Architectures httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000

2

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 10: Bachelor-Thesis_Julian_Suleder_181348.pdf

2 Grundlagen

23 JAX-RS - Java API for RESTful Web ServicesJava API for RESTful Web Services (JAX-RS) ist ein Application Programming Inter-face (API) welches die Konzepte von REST in Java vereinheitlicht und als Standardeinen Rahmen fuumlr das Entwickeln von RESTful Web Services bildet Der Standardsieht vor das Verhalten von Services durch Annotationen zu spezifizieren

Eine Menge von Services benoumltigt immer eine Application die den Basispfad derAnwendung festlegt Der Zugriff auf die in Listing 21 definierte Applikation erfolgtuumlber httpltservergtapirest

1 import javaxwsrsApplicationPath2 import javaxwsrscoreApplication3

4 ApplicationPath(apirest)5 public class RestApplication extends Application 6 public RestApplication () 7

Listing 21 Ein RESTful Web Service mit JAX-RS spezifiziert durch eineApplikation den Basispfad fuumlr den Zugriff auf Services

In Listing 22 ist die Methode eines Service definiert Sie ist durch die HTTP-Operationuumlber den angegebenen Pfad aufrufbar Zusaumltzlich werden die Formate die sie konsu-miert und produziert und die aus der Anfrage genutzten Parameter optional mitStandardwerten angegeben

1 import javaxwsrs2

3 Path(10 persons)4 public class PersonService 5 GET6 Path(person id)7 Produces(MediaTypeAPPLICATION_JSON)8 public Person getPerson(PathParam(id) int id DefaultValue

(Max Mustermann)QueryParam(name) String name)9 Person person = new Person ()

10 personsetName(name)11 return person12 13 14 public class Person15 private String name = 16 public String getName () return name 17 public void setName(String name) thisname=name 18

Listing 22 Eine Service-Methode die uumlber GET-Anfragen aufgerufen wird undJSON produziert Die Uumlbersetzung von Objekt zu JSON wird mitProvidern (Abschnitt 422) vorgenommen

3

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 11: Bachelor-Thesis_Julian_Suleder_181348.pdf

2 Grundlagen

24 Hybride ApplikationenEine hybride Applikation auch hybride App genannt ist eine mit gaumlngigen Webtech-nologien geschriebene Web-Applikation fuumlr mobile Geraumlte die lokal in einem Brow-serfenster einer sogenannten Web View gestartet wird Diese besitzt keine visuelleNavigation und Adresseingabe kann jedoch durch Erweiterungen auf die Geraumltefunk-tionalitaumlt zugreifen Das bekannteste Framework fuumlr hybride Apps ist Phonegap andessen Beispiel in Abschnitt 262 der Aufbau einer hybriden App erklaumlrt wird

25 Sicherheitsprobleme hybrider ApplikationenAuf Web-Anwendungen abzielende Angriffe bedrohen hybride Apps in gleichem MaszligeIm Folgenden werden die zwei groumlszligten Bedrohungen und clientseitigen Gegenmaszlignah-men zur Erschwerung eines Angriffes vorgestellt

bull Problem Bei einer Cross-Site-Request-Forgery (XSRF) wird das Vertrauen derWebanwendung in den Benutzer ausgenutzt Da HTTP zustandslos ist muss derBenutzer bei jeder Aktion auch Daten zur Authentifizierung mitsenden Dies ma-chen sich Angreifer bei XSRF-Angriffen zu Nutze Sie manipulieren zB durcheinen Man-in-the-Middle-Angrif den Code der Webseite Der Benutzer fuumlhrtanschlieszligend unwissentlich schaumldliche Aktionen zB eine Bestellung aus

bull Loumlsung Damit keine Skripte oder manipulierte HTML-Seiten bezogen werdenkoumlnnen wird mittels Same-Origin Policy (SOP) die Quelle von Ressourcen striktauf den Pfad der Anwendung beschraumlnkt Um daruumlber hinaus Zugriff auf weitereRessourcen zu gestatten werden vertrauenswuumlrdige Quellen durch Cross-OriginResource Sharing (CORS) in einer Whitelist erfasst Der Client uumlberpruumlft damitbereits vor der Anforderung der Ressource deren Vertrauenswuumlrdigkeit [4]

bull Problem Eine Web-Anwendung ist fuumlr Cross-Site Scripting (XSS) anfaumllligwenn sie Daten als Text von einem Server bezieht Zur Ausnutzung wird in denDaten ein script-Element gesendet Dazu muss der Angreifer die Antwort ab-fangen und manipulieren oder den Server uumlbernehmen Bei Ausfuumlhrung auf demClient kann der Angreifer sensible Daten des Benutzers stehlen und ausnutzen[5 S 133ff]

bull Loumlsung Um dies zu verhindern werden Eingaben maskiert dh gefaumlhrlicheFunktionszeichen durch ungefaumlhrliche Aumlquivalente ersetzt (zB lt durch amplt)Diese Ersetzung wird erst bei der Darstellung durch die Web View ruumlckgaumlngiggemacht und verhindert die Ausfuumlhrung von Code waumlhrend der VerarbeitungWerden Skripte aktiv nachgeladen so muumlssen die Quellen zusaumltzlich zur SOPebenfalls in einer Content Security Policy (CSP) Whitelist erfasst werden An-derenfalls wird die Ausfuumlhrung des Codes verhindert

4

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 12: Bachelor-Thesis_Julian_Suleder_181348.pdf

2 Grundlagen

26 Middleware-FrameworksIn diesem Abschnitt werden Frameworks fuumlr die Realisierung oder Erweiterung derSchnittstelle zwischen nativem Betriebssystem und hybrider Anwendung vorgestellt

261 AngularJS

AngularJS ist eine Open-Source-JavaScript-Bibliothek die von Google weiterentwi-ckelt und unterhalten wird Die fuumlr das Projekt wichtigsten Eigenschaften sind dieleichte Erweiterbarkeit und Modularisierung von AngularJS-Applikationen Depen-dency Injection sowie die Zwei-Wege-Datenbindung Die Zwei-Wege-Datenbindungermoumlglicht eine automatische Aktualisierung von Variablen-Werten bei Aumlnderungenan Oberflaumlche und Model Es erweitert HTML um die Wiederverwendung von Code-Ausschnitten zu erhoumlhen Dadurch wird die Grundlage geschaffen komplexe Anwen-dungen komfortabler und leichter zu erstellen [6 S 3]

Eine AngularJS-Applikation gliedert sich in Module Jedes Modul ist eine eigenstaumln-dige Applikation und in AngularJS mit eindeutigem Namen Navigation Konstantenund Controllern definiert Ein Modul kann Abhaumlngigkeiten zu anderen Modulen be-sitzen wofuumlr es einen eindeutigen Namen tragen muss

Die Navigation definiert die Zustaumlnde des Moduls Zustaumlnde sind Webseiten und besit-zen einen Namen und eine eindeutige URI zum Zugriff aus der Applikation Zusaumltzlichwird eine HMTL-Seite fuumlr die Darstellung des Zustands und ein Controller fuumlr dieDatenhaltung und Logik angegeben

Die Ressourcen der Applikation muumlssen vom Browser beim Start geladen werden koumln-nen Hierzu definiert jede AngularJS-Applikation eine indexhtml-Seite In ihr werdenim head alle JavaScript- und Cascading Style Sheets (CSS)-Files der Applikation ange-geben und im body eine AngularJS-Applikation mit einer Einstiegsseite definiert (sieheListing 23)

1 ltDOCTYPE htmlgt2 lthtmlgt3 ltheadgt4 ltscript src=angularjsgtltscript gt5 ltscript src=appjsgtltscript gt6 ltheadgt7 ltbody ng-app=appgt8 lt--some nice web -page --gt9 ltbodygt

10 lthtmlgt

Listing 23 Beispiel der indexhtml einer AngularJS-Applikation

5

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 13: Bachelor-Thesis_Julian_Suleder_181348.pdf

2 Grundlagen

262 Apache Cordova Phonegap

Apache Cordova Phonegap ist eine Zusammenstellung von Geraumlte-APIs die einemEntwickler mobiler Apps Zugriff zu nativen Geraumltefunktionen wie zB der Kameraoder dem Beschleunigungsmesser mit JavaScript ermoumlglichen In Kombination miteinem UI-Framework erlaubt es eine Smartphone-App mit HTML CSS und Java-Script zu entwickeln [7] Im Oktober 2012 wurde PhoneGap in die Apache SoftwareFoundation (ASF) unter dem Namen Apache Cordova integriert und erhielt Top-Level-Projekt-Status [8]

Abbildung 21Architektur einer Cordova-Applikation [9 S 192]

Die Architektur einer Cordova-Applikation ist in Abbil-dung 21 dargestellt Die hybride App besteht aus generi-schen Anteilen der Cordova-API und anwendungspezifi-schem Code Die Anwendung wird in der Web View gela-den und angezeigt Uumlber das cordovajs-File erhaumllt sieZugriff auf grundlegende native Geraumltefunktionalitaumltenund erweiternde Cordova-Plugins Diese beinhalten einennativen und einen JavaScript-Anteil Nativer plattform-spezifischer Code wird uumlber den generischen JavaScript-Code abstrahiert wodurch die Komplexitaumlt der nativenImplementierungen verborgen wird Dies hat zur Folgedass die Applikation rein mit gaumlngigenWebstandards pro-grammiert werden kann Beim Build wird ein Artefakt fuumlrjede gewuumlnschte Plattform erzeugt Die fertige App wirktdabei bis auf die HTML5-Oberflaumlche nahezu vollstaumlndignativ [9 S 191f] Fuumlr die Entwicklung wird das nativeSoftware Development Kit (SDK) einer Plattform benouml-tigt (bspw AndroidStudio fuumlr Android- und Xcode fuumlriOS-Entwicklung)

263 Appcelerator

Appcelerator ist ein kostenpflichtiges Framework zur Entwicklung hybrider Applika-tionen das Services wie zB die Bereitstellung kompletter Cloud-Backends fuumlr mobileApplikationen (Mobile Backend as a Service (MBaaS)) oder App-Analyse-Methodenanbietet [10] Auf Grund der Kosten und mangelnder NFC-Schnittstelle wurde dasFramework ausgeschlossen

264 FireMonkey

FireMonkey ist ein kostenpflichtiges Framework fuumlr die Entwicklung geraumlteuumlbergreifen-der nicht nur mobiler nativer Anwendungen unter Verwendung von HTML5 Delphioder C++ [11] Auf Grund der Kosten wurde das Framework ausgeschlossen

6

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 14: Bachelor-Thesis_Julian_Suleder_181348.pdf

2 Grundlagen

265 Intel XDK

Intel XDK ist eine kostenfreie Entwicklungsumgebung von Intel fuumlr die Entwick-lung von Cordova-Apps Die Entwicklungsumgebung enthaumllt einige hilfreiche Werk-zeuge und Erweiterungen fuumlr zB die Entwicklung von Spielen oder Einbindung vonMultimedia-Inhalten [12]

266 NativeScript

NativeScript ist ein Framework fuumlr mobile Applikationen das es Entwicklern ermoumlg-licht native Apps fuumlr iOS und Android zu erstellen ohne plattformspezifischen Codeschreiben zu muumlssen [13] Auf Grund mangelnden Zugangs zum NFC-Sensor wurdedas Framework ausgeschlossen

267 Sencha Touch

Sencha Touch ist ein Framework zur Entwicklung hybrider Applikationen dass uumlberdie Cordova-Funktionalitaumlt hinaus weitere Geraumltefunktionalitaumlt bereitstellt Es verein-facht die Realisierung performanter nativ aussehender Applikationen uumlber vorgefertig-te Erweiterungen [14] Auf Grund der Kosten wurde das Framework ausgeschlossen

268 TriggerIO

TriggerIO ist ein Framework fuumlr mobile Applikationen Es abstrahiert aumlhnlich wieCordova plattformspezifische Implementierungen in Bibliotheken die uumlber JavaScriptgenerisch nutzbar sind [15] Auf Grund der Kosten und mangelnden Zugang zum NFC-Sensor wurde das Framework ausgeschlossen

269 Xamarin

Xamarin ist ein Framework fuumlr die Entwicklung mobiler Applikationen mit C Esbietet Services zum automatischen Build Testen und App-Monitoring an Zusaumltzlichverfuumlgt es uumlber umfassende Schnittstellen um den Backend-Zugriff mit verschiedens-ten Technologien zu vereinfachen [16] Auf Grund der Kosten wurde das Frameworkausgeschlossen

27 UI-FrameworksIn diesem Abschnitt werden Frameworks fuumlr hybride Applikationen vorgestellt die sichauf die Oberflaumlche spezialisiert haben Diese werden fuumlr die Entwicklung in Verbindungmit einem Middleware-Framework (Abschnitt 26) verwendet oder beinhalten dieses

7

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 15: Bachelor-Thesis_Julian_Suleder_181348.pdf

2 Grundlagen

271 AppGyver

AppGyver ist ein kostenpflichtiges auf dem Ionic Framework (273) basierendes Fra-mework fuumlr hybride Applikationen das besonderen Wert auf die Nativitaumlt der Benut-zeroberflaumlche legt [17] Auf Grund der Kosten wurde das Framework ausgeschlossen

272 Famous

Famous ist ein Framework fuumlr die Entwicklung vonWebseiten mit spieleaumlhnlichen Ani-mationen und Visualisierungen mit Webstandards [18] Das Framework wurde ausge-schlossen da es zwar mit Cordova fuumlr hybride Applikationen verwendet werden kannaber primaumlr fuumlr Webseiten gedacht ist

273 Ionic Framework

Ionic ist ein umfangreiches HTML5 Framework fuumlr die Entwicklung von hybriden Ap-plikationen Es fokussiert sich auf die Benutzeroberflaumlche der Applikation und baut aufPhonegap und AngularJS auf Das quelloffene Framework beinhaltet zahlreiche Toolszur Unterstuumltzung der effizienten Entwicklung und Personalisierung der Applikationwie zum Beispiel die Automatisierung des Build-Prozesses [19] Die zu entwickelndehybride Applikation wurde auf Grund dieser Vorteile mit Ionic umgesetzt

274 jQuery Mobile

jQuery Mobile ist ein User Interface (UI)-Framework fuumlr mobile WebanwendungenIn Verbindung mit PhonegapCordova koumlnnen hybride Applikationen mit komplexenOberflaumlchen erstellt werden [20]

275 Kendo UI

Kendo UI ist ein auf jQuery basierendes Framework fuumlr die Entwicklung hybriderApplikationen mit optionaler Einbindung von AngularJS oder Twitter Bootstrap3 Esbringt viele vorgefertigte UI-Bausteine und Werkzeuge mit [21] Auf Grund der Kostenwurde das Framework ausgeschlossen

276 Onsen UI

Onsen UI ist ein Open-Source HTML5 Oberflaumlchen-Framework das einerseits fuumlr Web-sites andererseits unter Verwendung von AngularJS und PhonegapCordova fuumlr hybri-de Applikationen verwendet werden kann Es soll nach eigenen Angaben performanterals andere UI Frameworks sein [22]

3Twitter Bootstrap httpgetbootstrapcom

8

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 16: Bachelor-Thesis_Julian_Suleder_181348.pdf

2 Grundlagen

28 REST-FrameworksIn diesem Abschnitt werden die verbreitetsten Implementierungen des JAX-RS-Standardsvorgestellt

281 Apache CXF

Die REST-Erweiterung fuumlr das umfangreiche Webservice-Framework Apache CXF un-terstuumltzt viele Transportprotokolle und zusaumltzliche Module fuumlr die Entwicklung vonREST-Services Das Framework ist darauf ausgelegt moumlglichst viele DatenformateTransportprotokolle und Standards zu unterstuumltzen [23]

282 Jersey

Die JAX-RS-Implementierung Jersey ist die Referenzimplementierung des Standardsund bietet zusaumltzliche Werkzeuge fuumlr die Entwicklung von REST-Services und -ClientsDas Framework wird mit den Updates des Standards weiterentwickelt [24]

283 RESTEasy

RESTEasy ist ein Framework von JBoss fuumlr die Entwicklung von RESTful Web Ser-vices Es ist eine vollstaumlndig konforme Implementierung des JAX-RS Standards Esbietet uumlber diesen Standard hinaus weitere umfangreiche Funktionen wie zB ei-ne Client-API und viele Provider fuumlr Transportprotokolle und Datenformate [25] Eswurde fuumlr die Implementierung des REST-Backends der hybriden Applikation ausge-waumlhlt

284 Restlet Framework

Das Restlet Framework war das erste Framework zur Entwicklung von REST-Servicesbevor diese populaumlr wurden und kann in einer Vielzahl von Umgebungen verwendetwerden Es integriert den JAX-RS Standard als Erweiterung des Frameworks undermoumlglicht es Anwendungen nicht zwangslaumlufig auf einem Anwendungsserver einsetzenzu muumlssen [26]

9

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 17: Bachelor-Thesis_Julian_Suleder_181348.pdf

3 Anforderungsanalyse

In diesem Kapitel wird zunaumlchst der grundlegende Gedanke der Applikation (Ab-schnitt 31) erlaumlutert und deren Nutzungskontext (Abschnitt 32) beschrieben Demfolgen die Anforderungen an das System welche mit den Papierentwuumlrfen der Be-nutzerschnittstelle im Abschnitt 35 die Grundlage fuumlr die Technologieevaluation inKapitel 4 bilden

31 Kerngedanken der ApplikationNach den in Abschnitt 12 vorgestellten Zielen soll eine hybride Applikation fuumlr dieAndroid-Plattform entwickelt werden Der Nutzer liest mit der Applikation uumlber denNFC-Sensor seines Smartphones die Seriennummer seiner Mensakarte oder einem be-liebigen anderen NFC-Tag aus und verknuumlpft diese mit seinem Benutzerkonto DieseVerknuumlpfung kann er zB bei Verlust der Karte ruumlckgaumlngig machen (vgl Abbildung31)

Abbildung 31 Die Verknuumlpfung einer Karte und die Loumlsung dieser Verknuumlpfung sinddie primaumlren Anwendungsfaumllle an das System Um diese Aktionendurchfuumlhren zu koumlnnen muss sich der Benutzer als Angehoumlriger derHHN ausweisen koumlnnen Externe Systeme koumlnnen die Benutzer uumlberdie Karten identifizieren

10

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 18: Bachelor-Thesis_Julian_Suleder_181348.pdf

3 Anforderungsanalyse

32 NutzungskontextDer Nutzungskontext beinhaltet benutzer- und systemspezifische Merkmale

bull Benutzermerkmale Der Benutzer ist in der Hochschule Heilbronn als Mitar-beiter oder Student registriert und besitzt ein aktives Benutzerkonto sowie eineMensakarte des Studentenwerks Heidelberg Da die Benutzergruppe hinsichtlichihrer technischen Affinitaumlt heterogen zusammengesetzt ist wird der Benutzer imAllgemeinen als Laie angesehen

bull Umgebung des Systems Der Zugriff auf das System erfolgt via Internet uumlbermeist ungesicherte Zugaumlnge wie zB Mobile Netze oder oumlffentliche WLAN-Netzwerke Die App soll vorwiegend fuumlr Smartphones entwickelt werden dieBildschirmgroumlszlige ist nicht festgelegt

33 Funktionale AnforderungenAus dem Nutzungskontext (Abschnitt 32) und den grundlegenden Gedanken hinterder App (Abschnitt 31) leiten sich folgende funktionale Anforderungen ab

bull Funktionaler Schwerpunkt der Applikation soll die Registrierung und Deregis-trierung von NFC-Tags sein Die Integration von Standardinhalten einer Appli-kation wie zum Beispiel ein Impressum kann beruumlcksichtigt werden die Inhaltesind zu vernachlaumlssigen

bull Der Benutzer soll testen koumlnnen ob sein Smartphone einen NFC-Sensor besitzt

bull Ist ein solcher Sensor vorhanden soll der Benutzer durch das Ausloumlsen einerAktion nach einer Karte suchen Dies soll so lange geschehen bis eine Karteerkannt wurde oder der Benutzer die Suche abbricht

bull Wird eine Karte erkannt soll die Seriennummer der Karte automatisch ausgele-sen werden

bull Der Benutzer soll die Seriennummer der Karte mit seinem Benutzerkonto derHochschule verknuumlpfen koumlnnen Hierfuumlr soll ein Formular mit BenutzernamenPasswort und der Seriennummer der Karte vorhanden sein

bull Der Benutzer muss die Verknuumlpfung der Karte aktiv ausloumlsen und Ruumlckmeldunguumlber Erfolg und Misserfolg erhalten Ein Benutzer soll maximal eine Karte mitseinem Konto verknuumlpfen koumlnnen Ist eine Karte bereits verknuumlpft soll diesedurch die neue Karte ersetzt werden

bull Die Deregistrierung soll durch Eingabe von Benutzername und Passwort erfolgen

11

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 19: Bachelor-Thesis_Julian_Suleder_181348.pdf

3 Anforderungsanalyse

34 Nichtfunktionale Anforderungenbull Der Zugriff auf die Karte ist in jedem Moment lesender Art

bull Die App muss auf Android-Smartphones und -Tablets bis August 2015 funktio-nieren und darf keine Kosten verursachen

bull Die Oberflaumlche soll vorerst nicht internationalisiert werden aber leicht verstaumlnd-lich und gut bedienbar sein Ein ansprechendes Design wird geringer priorisiertals die Funktionalitaumlt

bull Die Leistungsfaumlhigkeit des Systems soll auch durch gleichzeitige Nutzung durchmehrere Benutzer in tolerierbarer Zeit erfolgen Besondere Maszlignahmen muumlssendafuumlr nicht umgesetzt werden

bull Da in naher Zukunft eine Integration weiterer Funktionalitaumlt in die App erfolgensoll sollte der Entwurf der App eine Modularitaumlt und leichte Erweiterbarkeitaufweisen dabei ist eine Versionierung von App und Schnittstelle zum ServerPflicht

bull Die Nutzung der App in unsicheren Netzwerken ist grundsaumltzlich risikobehaftetDaher muumlssen Maszlignahmen zur Absicherung hybrider Applikationen beruumlcksich-tigt werden

35 Initiale GestaltungsloumlsungIn diesem Abschnitt werden als Ergebnis des Nutzungskontexts und der funktionalenAnforderungen aus Abschnitt 32 und 33 die initialen Gestaltungsloumlsungen der Benut-zeroberflaumlche fuumlr die Registrierung und Deregistrierung von NFC-Tags dargestellt

351 Papierentwurf der Registrierung

In Abbildung 32 ist ein Zustandsdiagramm abgebildet das die Zustaumlnde der Regis-trierung darstellt Auf dessen Basis wurde ein Registrierungsassistent erstellt der denBenutzer durch die Registrierung fuumlhrt Zunaumlchst muss der Status des Sensors uumlber-pruumlft werden Ist dieser vorhanden und aktiviert kann die Suche nach einer Kartegestartet werden Nach dem Auslesen werden die Benutzerdaten benoumltigt Sind diesekorrekt so erfolgt die Verknuumlpfung

12

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 20: Bachelor-Thesis_Julian_Suleder_181348.pdf

3 Anforderungsanalyse

Abb

ildun

g32

Das

Zustan

dsdiag

ramm

zeigtdieZu

staumln

dederRegistrierung

vonNFC

-Tag

smit

denmoumlg

lichenAlter-

nativzustaumlnd

enEswirdan

geno

mmenda

ssich

derStatus

desSensorswaumlh

rend

derBenutzung

nicht

aumlndert

13

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 21: Bachelor-Thesis_Julian_Suleder_181348.pdf

3 Anforderungsanalyse

Abbildung 33 Papierbasierter Prototyp der Startseite des Registrierungsassistentenmit Hinweisen zum benoumltigten NFC-Sensor In der rechten Abbildungist die Statuserfassung des Sensors gestartet ndash ein modaler Dialog wirdangezeigt Dieser verschwindet wenn der Status des Sensors erfasst ist

Abbildung 34 Papierbasierter Prototyp der Meldungen falls ein deaktivierter Sensorgefunden wurde (links) ein Fehler auftrat oder kein Sensor gefundenwurde (rechts)

14

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 22: Bachelor-Thesis_Julian_Suleder_181348.pdf

3 Anforderungsanalyse

Abbildung 35 Prototyp der Kartenerfassung Ein aktivierter Sensor muss gefundenworden sein Beim Start der Erfassung wird so lange ein Dialog geoumlff-net bis eine Karte gelesen oder die Erfassung abgebrochen wurde

Abbildung 36 Prototyp des Absendeformulars der Registrierung Der Nutzer mussBenutzername und Passwort eintragen Die Seriennummer der einge-lesenen Karte wird automatisch ausgefuumlllt Sind die Benutzerdaten un-guumlltig so wird eine entsprechende Meldung angezeigt und das Pass-wortfeld geleert War die Verknuumlpfung erfolgreich wird eine Meldungangezeigt

15

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 23: Bachelor-Thesis_Julian_Suleder_181348.pdf

3 Anforderungsanalyse

352 Papierentwurf der Deregistrierung

In Abbildung 37 sind die moumlglichen Zustaumlnde bei der Loumlsung von Verknuumlpfungen zusehen Die daraus entwickelte Oberflaumlche besteht auf Grund der geringen Komplexitaumltaus einem einzigen Formular

Abbildung 37 Zustaumlnde bei der Loumlsung der Verknuumlpfung Nach dem Versenden derBenutzerdaten wird der Statustext aktualisiert

In den nachfolgenden Papierentwuumlrfen ist die Oberflaumlche fuumlr die Deregistrierung derNFC-Tags dargestellt

Abbildung 38 Papierbasierter Prototyp der Deregistrierung Es werden der Benutzer-name und das Passwort des Benutzers benoumltigt Ist die Verknuumlpfungerfolgreich oder sind die Anmeldedaten unguumlltig wird eine geeigneteMeldung angezeigt

16

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 24: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

In diesem Kapitel werden nach den Anforderungen und Restriktionen aus Kapitel 3Kriterien fuumlr Frameworks fuumlr hybride Applikationen und Implementierungen desJAX-RS 20-Standards aufgestellt anschlieszligend an den am Markt vorhandenen Loumlsun-gen evaluiert Als Ergebnis dieser Analyse wird jeweils ein Framework fuumlr die Realisie-rung des Teilsystems ausgewaumlhlt In Abschnitt 43 werden verschiedene Moumlglichkeitender Versionierung von REST-Services vorgestellt und deren Vor- und Nachteile disku-tiert

41 Frameworks fuumlr hybride AppsDie nachfolgenden Anforderungen ergeben sich aus den Anforderungen und Restrik-tionen (Abschnitt 33 und 34) fuumlr Frameworks hybrider Apps

411 Formulierung Muss-Kriterien

Die folgenden Kriterien muumlssen von einer potentiellen Loumlsung vollstaumlndig erfuumlllt wer-den Die Nichterfuumlllung eines Kriteriums fuumlhrt zum Ausschluss der Loumlsung aus derweiteren Analyse

bull Kostenmodell Das Framework muss vollstaumlndig kostenfrei verfuumlgbar sein Diesgilt auch fuumlr die Dokumentation und gegebenenfalls verfuumlgbare Tutorials Es darfauch nach der Entwicklung keine Folgekosten nach sich ziehen

bull Lizenzmodell Die Software muss vollstaumlndig quelloffen sein und auf Open-Source-Software1 basieren

bull Plattform Die Android-Plattform muss ab Version 44 aufwaumlrts unterstuumltztwerden

bull NFC Zugang zum NFC-Sensor des Smartphones muss uumlber das Frameworkdirekt oder ein entsprechendes Plugin zugesichert werden

bull Release Das Framework soll auf neueren Technologien basieren und bis zurImplementierung der Anwendung im Mai 2015 ein stabiles Release vorweisenkoumlnnen

1Die einzelnen Lizenzen koumlnnen unter httpopensourceorg eingesehen werden

17

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 25: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

412 Auswertung Muss-Kriterien

Muss-Kriterien NativeScript Ionic XamarinKosten Keine Keine $999aLizenz Apache 20 MIT LGPLv2Android Ja Ja JaNFC Nein Ja2 JaRelease Zukunft Juni 2015 Stabil StabilMuss-Kriterien Famous Kendo UI AppGyverKosten Keine $699a $199aLizenz MPLv2 Kommerziell3 KommerziellAndroid Nein4 Ja JaNFC Ja2 Ja5 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien TriggerIO FireMonkey Onsen UIKosten $79m Auf Anfrage keineLizenz Kommerziell Kommerziell Apache 20Android Ja Ja JaNFC Nein Ja6 Ja2

Release Zukunft Stabil Stabil StabilMuss-Kriterien Intel XDK Sencha Touch AppceleratorKosten keine $3855a $39mLizenz Eigene Kommerziell KommerziellAndroid Ja Ja JaNFC Ja2 Ja NeinRelease Zukunft Stabil Stabil StabilMuss-Kriterien Standardtechnologien7

Kosten keineLizenz Phonegap Apache 20 AngularJS JQueryMobile MITAndroid JaNFC Ja2

Release Zukunft Stabil

2Mit Cordova Plugin httpsgithubcomchariotsolutionsphonegap-nfc3Kern-Bibliothek mit Apache 20 Rest httpwwwtelerikcompurchaselicense-agreementkendo-ui-professional

4Framework ist primaumlr fuumlr Websites gedacht nur durch Kombination mit PhonegapCordova5Uumlber Plugin httppluginstelerikcompluginnfc6Durch Community-Plugin httpstackoverflowcomquestions24650883firemonkey-android-nfc-adapter

7PhonegapCordova AngularJS JQuery

18

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 26: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

Auswertung der Muss-Kriterien

Durch die Nichterfuumlllung von Kriterien und die Disqualifikation der Frameworks wer-den in den weiteren Abschnitten die Frameworks Ionic (Abschnitt 273) Onsen UI(Abschnitt 276) Intel XDK (Abschnitt 265) und eine Komposition aus Standard-technologien (Cordova - 262 AngularJS - 261 JQuery Mobile - 274) mit denweiteren Kriterien evaluiert

413 Formulierung Soll-Kriterien

Die folgenden Kriterien sollten von einer potentiellen Loumlsung erfuumlllt werden um eineschnelle und effiziente Entwicklung und Wartung zu ermoumlglichen

bull Homogenes Framework Geringe Fragmentierung der benutzten Frameworks fuumlrmoumlglichst geringen Wartungsaufwand

bull Verfuumlgbarkeit von kostenlosen Einstiegs-Tutorials und -Dokumentation

bull Freie Wahl der Entwicklungsumgebung dh keine Bindung an frameworkspe-zifische Werkzeuge Zudem sollten geringe Systemvoraussetzungen an Softwareund Hardware bestehen

bull Erweiterte Tools zur einfachen Testbarkeit und Entwicklung der App direkt aufdem Geraumlt oder im Browser Cordova bietet bereits Funktionalitaumlt zum Test derApp auf Geraumlt oder Emulator

bull Verbreitung Bereits auf dem Markt etablierte Frameworks finden in vielen Louml-sungen Anwendung Durch ihre hohe Verbreitung sind Weiterentwicklung undkontinuierliche Beseitigung von Fehlern zugesichert

bull Erweiterbarkeit und Wartung des Frameworks In das Framework sollen moumlg-lichst regelmaumlszligig neue Funktionen integriert werden Die Aktualisierung solltemit moumlglichst wenig Aufwand durchfuumlhrbar sein

19

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 27: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

414 Auswertung Soll-Kriterien

Soll-Kriterien Ionic Onsen UIHomogenitaumlt desFrameworks

Kapselung aller genutztenTechnologien (Cordova An-gularJS UI) Bereitstellungder Funktionalitaumlt der APIsuumlber Command Line Inter-face (CLI)

Bereitstellung des reinenUI-Frameworks Manu-elle Verknuumlpfung mitPhongapCordova undAngularJS noumltig

Tutorials Do-kumentation(kostenlos)

Einstiegsdokumentationfuumlr Installation Dokumen-te fuumlr CLI Entwicklungbis Ausrollen in App-Store beschrieben GrobeDokumentation uumlber CSS-Styles des FrameworksVerweis auf die AngularJS-Dokumentation FAQund offizielle Communityvorhanden

Detailierte Dokumentati-on der UI-Komponentendetaillierte Beschreibungder einzelnen HTML-Tagsund CSS-Styles Instal-lation und Einrichtungdes Frameworks sehr kurzbeschrieben Keine offizielleCommunity vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Keine Bindung an speziel-le Werkzeuge Ionic wird alsNodeJS-Modul mit Cordovaund AngularJS automatischbei der Installation herun-tergeladen und eingerichtet

Eigenes Werkzeug zur Ent-wicklung verfuumlgbar keineBindung an ein WerkzeugWird als NodeJS-Modulheruntergeladen ManuelleInstallation

Testbarkeit derApp direkt aufGeraumltEmulator

Die App kann waumlhrendder Entwicklung direkt imBrowser gestartet werdenAumlnderungen werden liveuumlbernommen

Keine eigenen Hilfestellun-gen vorhanden

Basierend auf ver-breiteten Technolo-gien

Ionic UI enthaumllt Elementevon JQuery Mobile

Basiert auf keinen anderenTechnologien

Erweiterbarkeitund Wartung

AngularJS Version 2 er-schienen Ionic plant die In-tegration Ionic staumlndigesRelease von Features Up-date durch CLI-Befehl auto-matisch

Keine Informationen uumlberUI-Framework selbst Ma-nuelle Suche nach neuenVersionen und Aktualisie-rung

20

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 28: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

Soll-Kriterien Intel XDK StandardtechnologienHomogenitaumlt desFrameworks

Entwicklungsumgebungkapselt PhonegapCordova

Die einzelnen APIs werdenmanuell miteinander ver-bunden

Tutorials Do-kumentation(kostenlos)

Keine Tutorials zur Ent-wicklung mit HMTL5 Do-kumentation zur Installati-on und Inbetriebnahme derEntwicklungsumgebung

Tutorials und Dokumenta-tion der einzelnen Techno-logien Community fuumlr alleTechnologien vorhanden

Bindung an Werk-zeuge Systemvor-aussetzungen

Eine Entwicklung mit an-deren Werkzeugen als IntelXDK scheint nicht vorgese-hen zu sein

Freie Wahl der Entwick-lungsumgebung

Testbarkeit derApp direkt aufGeraumltEmulator

Das Integrated Develop-ment Environment (IDE)bietet Moumlglichkeiten dieApp visuell mit denCordova-Mitteln zu TestenEine Entwicklung mit bdquoLiveLayout Editingldquo der Seitenist moumlglich

Debugging uumlber verwen-dete Entwicklungsumge-bung oder mit Browser-Entwicklertools moumlglich

Basierend auf ver-breiteten Technolo-gien

Kapselt PhonegapCordo-va

Repraumlsentieren die Stan-dardtechnologien desMarkts

Erweiterbarkeitund Wartung

EntwicklungsumgebungUpdates als einziges MittelAusreichend Funktio-nalitaumlt fuumlr unerfahreneBenutzer Fortgeschrittenevermissen schnell weite-re Funktionen wie zBCode-Vervollstaumlndigung

Wartung der einzelnen Fra-meworks sehr einfach Re-gelmaumlszligige AngularJS- undJQuery mobile -Releasesvorhanden

415 Ergebnis

Intel XDK (Abschnitt 265) scheint fuumlr Einsteiger durch Vorgabe der Entwicklungs-umgebung viele hilfreiche Funktionen zu besitzen und erleichtert durch die grafischeBenutzeroberflaumlche den Einstieg in die Entwicklung hybrider Applikationen Erfahre-nere Benutzer vermissen schnell weitere Funktionalitaumlt und zusaumltzliche Dokumentati-on

21

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 29: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

Onsen UI (Abschnitt 276) besticht durch die aumluszligerst detaillierte DokumentationInformationen zu regelmaumlszligigen Updates und Funktionserweiterungen sind nicht ver-fuumlgbar Potenziell vorhandene Vorteile gegenuumlber anderen Frameworks wurden nichtevaluiert da die Geschwindigkeit des Seitenaufbaus die Vielfalt an Oberflaumlchenkom-ponenten und Animationen keine fuumlr die Applikation essentiellen Faktoren sind

Das Aggregat der Standardtechnologien bietet durch deren breite Online-Communityausreichende Hilfestellung fuumlr Einrichtung und Entwicklung einer hybriden Applika-tion Eine effiziente Entwicklung benoumltigt jedoch weitere unterstuumltzende Hilfsmittelund gegebenenfalls zusammenfassende Literatur da der Umfang der Dokumentationteilweise schwer uumlberschaubar ist oder Dokumente veraltet sind

Ionic Framework (Abschnitt 273) bietet durch die Kapselung von Standardtechnolo-gien die umfangreiche Dokumentation viele nuumltzliche Entwicklertools und regelmauml-szligige Aktualisierungen die reifeste Hilfestellung aller evaluierten Frameworks Diese istsowohl fuumlr Einsteiger als auch fuumlr fortgeschrittene Entwickler geeignet und wurde fuumlrdie Realisierung der hybriden Applikation ausgewaumlhlt

42 JAX-RS Implementierungen amp JSON-UmwandlungDer JAX-RS 20-Standard sieht alle fuumlr einen Entwurf mit Trennung von Service-Definition und -Implementierung noumltigen Hilfsmittel wie zB Annotationen vor (sie-he Abschnitt 23) Die Implementierungen des Standards unterscheiden sich in derHilfestellung der Konvertierung von Objekte zu Formaten wie der Extensible MarkupLanguage (XML) oder JSON ihrer Einrichtung und Funktionalitaumlt uumlber den Standardhinaus

Es gibt mehrere Verfahren Objekte in sprachunabhaumlngige Formate wie zB XMLund JSON zu konvertieren von denen die drei evaluiert werden Fuumlr das Projekt istbesonders das Datenformat JSON auf Grund der mit Webstandards zu entwickelndenhybriden Applikation relevant

In den folgenden Abschnitten werden die Vor- und Nachteile der manuellen (Abschnitt421) und automatischen Umwandlung von Objekten mittels Provider (Abschnitt422) sowie Java Architecture for XML Binding (JAXB) (Abschnitt 423) analysiertAlternativ zur Verwendung eines Frameworks wird in Abschnitt 424 die Loumlsung desServices uumlber ein Servlet vorgestellt

421 Manuelle Umwandlung mit Hilfsklassen

Die in Listing 41 abgebildete Klasse enthaumllt eine Methode fuumlr die JSON-UumlbersetzungDie verwendeten Hilfsklassen sind unter httpwwwjsonorgjavaindexhtml er-haumlltlich Felder komplexer Typen sowie Arrays und Collections muumlssen manuell kon-

22

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 30: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

vertiert Objektreferenzen auf null getestet und rekursiv in JSON umgewandelt wer-den

1 import orgjson 2

3 public class Person 4 private int id5 private String name = 6 private List ltPerson gt children = new ArrayList ltPerson gt()7

8 getter + setter9

10 public String getJSON () 11 JSONObject dataset = new JSONObject ()12 datasetput(name name)13 datasetput(id id)14 JSONArray list = new JSONArray ()15 for(Person p children)16 listadd(pgetJSON ())17 18 datasetput(children list)19 return datasettoString ()20 21

Listing 41 Beispiel fuumlr die manuelle Umwandlung von Objekten zu JSON Inden Zeilen 15ff befindet sich eine bei zyklischen Abhaumlngigkeitenentstehende Endlosschleife

Bezuumlglich der Erweiterbarkeit und Wartung des Codes sind Einschraumlnkungen gegebenDie Methode muss bei Ruumlckgabe ein Objekt vom Typ String zuruumlckgeben Der Servicemuss die Umwandlung des Objekts zu seiner JSON-Repraumlsentation aktiv durchfuumlh-ren Eine Auslagerung der Uumlbersetzung in den Service sorgt fuumlr eine engere Kopplungzwischen Service und Datentransferobjekt (DTO) besitzt aber den Vorteil dass derService nur die benoumltigten Felder des Objekts an Stelle einer universellen Repraumlsenta-tion uumlbersetzen muss Zusaumltzlich ist zu beachten dass beim Empfang von JSON dereinkommende String aufbereitet und in ein Objekt umgewandelt werden muss wasebenfalls aktiv durchgefuumlhrt werden muss

422 Automatische Umwandlung mit Provider

Mit Providern einer Schnittstelle fuumlr die Umwandlung beliebiger Medientypen dieder Standard in Form von Plug-Ins vorsieht werden Objekte automatisch in JSONkonvertiert ohne das diese annotiert sein muumlssen Die Implementierung eines solchenProviders ist jedoch nicht vom Standard abgedeckt sodass fuumlr jedes Framework einProvider vorhanden sein muss um nicht selbst einen solchen schreiben zu muumlssen

23

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 31: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

Der am weitesten verbreitete Provider fuumlr die JSON-Umwandlung ist Jackson Provi-der werden mit javaxwsrsextProvider annotiert und beim Start der Applikationautomatisch geladen dh es ist keine weitere Einrichtung noumltig sofern nicht mehre-re Provider fuumlr das selbe Datenformat oder unterschiedliche Datenformat-Schemataverwendet sollen Die Schnittstelle kann dadurch als Ruumlckgabe den Typ des Objektsbesitzen Listing 22 in Abschnitt 23 zeigt einen Service der Objekte der KlassePerson automatisch uumlber einen Provider in JSON uumlbersetzt

423 Automatische Umwandlung uumlber JAXB

Ein zu serialisierendes Objekt kann mit JAXB in beiden Richtungen in JSON undXML umgewandelt werden Klassen und Felder werden mit den in JAXB uumlblichenAnnotationen zum Mapping versehen Die Verbindung zwischen JAX-RS und JAXBwird durch einen Provider hergestellt Das Mapping zu XML und JSON kann durchexplizite Angabe eines Schemas in der Klasse veraumlndert werden Alternativ koumlnnenJAXB-Mapper geschrieben werden die das Mapping von Objekt zu XML festlegen

1 import javaxxmlbindannotationXmlElement2 import javaxxmlbindannotationXmlRootElement3

4 XmlRootElement5 public class Person 6

7 private int id=08 private String name=9

10 XmlElement11 public int getId() return id 12 public void setId(int id) thisid = id13

14 XmlElement15 public String getName () return name 16 public void setName(String name) thisname = name 17

Listing 42 Zu serialisierende Objekte muumlssen mit den JAXB-Annotationenversehen werden Der Provider wandelt das Ergebnis die Eingabeuumlber JAXB automatisch um

1 personid1nameJAXB Umwandlung mit JAXB2 id1nameProvider Umwandlung mit Provider

Listing 43 Das Ergebnis unterscheidet sich in seiner Form Bei der Umwandlungmit JAX-B muss ein Wurzelelement vorhanden sein

24

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 32: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

424 Alternativloumlsung mit Servlets

Bei diesem Ansatz wird kein Framework fuumlr die REST-Schnittstelle benutzt Ein Serv-let wartet auf Anfragen delegiert die Objekterzeugung an eigene Service-Klassen undgibt die Ergebnisse zuruumlck Dieser Ansatz ist fuumlr den Entwickler sehr aufwaumlndig dabei komplexen Anfragen alle Parameter aus der Uniform Resource Locator (URL)extrahiert encodiert und zB nach Typ und Wertebereich validiert werden muumlssenbevor eine Verarbeitung der Anfrage moumlglich ist

1 import javaio2 import javaxservletServletException3 import javaxservlethttp 4

5 public class ServiceServlet extends HttpServlet 6

7 protected void doGet(HttpServletRequest request 8 HttpServletResponse response) throws ServletException

IOException 9 PrintWriter out = responsegetWriter ()

10 String url = requestgetPathInfo ()11 int id = 012 String name = no name specified13 if (urlstartsWith(person)) 14 url = urlsubstring(personlength () urllength ())15 try 16 id = IntegerparseInt(url)17 catch (Exception e) 18 outprintln(id not valid)19 20 if (requestgetParameterMap ()containsKey(name)) 21 name = requestgetParameter(name)22 23 24 outprintln(PersonServicegetPerson(id name))25 outclose ()26 27

Listing 44 Beispiel-Servlet

Es ist zu beachten dass das Servlet in der webxml der Anwendung registriert und aufden Basispfad gemappt werden muss Es ist daher sinnvoll fuumlr die einzelnen Servicesund deren Versionen jeweils ein eigenes Servlet zu implementieren Diese werden dannauf verschiedene Pfade registriert und koumlnnen in der webxml gezielt aktiviert unddeaktiviert werden um Schnittstellen zu deaktivieren und neue hinzuzufuumlgen

25

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 33: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

425 Ergebnis

Fuumlr die Entwicklung des REST-Services wird die JAX-RS-Implementierung RESTEasyverwendet Durch die Vielzahl an verfuumlgbaren Providern fuumlr Datenformate und um-fassende Contexts and Dependency Injection (CDI) zur Registrierung von Servicesund der Einrichtung des Frameworks minimiert sich der Entwicklungsaufwand mitRESTEasy erheblich Zwar sind das Restlet Framework und Apache CXF bezuumlglichdes Funktionsumfangs maumlchtiger als RESTEasy oder Jersey jedoch ist die Einarbei-tung und Einrichtung beider Frameworks aufwaumlndiger Jersey die Referenzimplemen-tierung des Standards bietet eine Alternative zu RESTEasy jedoch sind nicht fuumlr alleDatenformate entsprechend flexible Provider verfuumlgbar Die Auswahl erfolgt nach Im-plementierung eines Test-Services unter Verwendung von RESTEasy und Jersey sowieden verschiedenen Moumlglichkeiten zur JSON-Objekt-Umwandlung

Fuumlr die Umwandlung von Java-Objekten in JSON und umgekehrt wurde das Verfahrenuumlber JAXB ausgewaumlhlt Durch das Annotieren der zu uumlbersetzenden Felder besitzt derAnsatz die Flexibilitaumlt bezuumlglich multipler Repraumlsentationen des gleichen Objekts oderSchemaaumlnderungen der Ausgabe Die manuelle Uumlbersetzung mit Hilfsklassen besitzteine aumlhnliche Flexibilitaumlt der initiale Aufwand fuumlr die Entwicklung der umkehrbarenUumlbersetzung ist jedoch houmlher Provider bilden einen Mittelweg zwischen manueller undkontrollierter automatischer Uumlbersetzung mit JAXB Bei Anpassung von Schemataoder partieller Uumlbersetzung von Objekten steigt jedoch auch hier der Aufwand

43 Versionierung von App und Server-BackendIn diesem Abschnitt werden verschiedene Moumlglichkeiten der Versionierung von REST-Services vorgestellt

REST-Services brauchen nicht aktiv versioniert werden da in der Regel nur die Res-sourcen veraumlnderlich sind bzw bei Erweiterungen neue Services implementiert oderweggelassen werden Haumlufig werden jedoch einfache Remote Procedure Calls (RPCs)uumlber HTTP durchgefuumlhrt Diese aumlhneln stark den Prinzipien von REST und muumlssenversioniert werden Diese sind die Codierung in die URL (Abschnitt 431) und dieCodierung in den Medientyp (Abschnitt 432)

Eine Versionierung der Smartphone-App fuumlr Android wird nicht durchgefuumlhrt da beider Veroumlffentlichung die letzte Version benoumltigt wird Aumlltere Versionen koumlnnen durchbei der Entwicklung verwendete Versionskontrollwerkzeuge wiederhergestellt werdenEine Benennung der Versionen wird nach den Google Richtlinien ([27]) durchgefuumlhrt

26

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 34: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

431 URL-Codierung

Ein weit verbreiterter Ansatz zur Versionierung von Services ist die Codierung der Ver-sionsnummer in die URL Pro URL koumlnnen die verschiedenen Medientypen wie zBJSON XML Text konsumiert und produziert werden Durch die URL-Versionierungmuss fuumlr jede neue Service-Version unter Umstaumlnden der komplette Service-Baum du-pliziert werden Ist die URL nicht mehr guumlltig weil die aumlltere Version eines Servicedeaktiviert wurde so wird vom Server der HTTP-Statuscode 404 (Not found) zu-ruumlckgegeben da es keine entsprechende Ressource gibt

Abbildung 41 Versionierung eines REST-Service uumlber die URL

Es ist ersichtlich dass die Versionierung nicht eindeutig erfolgen muss was das Wartender Schnittstelle aufwaumlndiger gestaltet Der URL-Baum kann sich an jedem beliebigenPunkt veraumlsteln was weitere Komplexitaumlt und Code-Duplizierung zur Folge hat AlsKonsequenz sollte die Schnittstelle so konzipiert werden dass sie Vertrag der Kommu-nikation zwischen Client und Server ist und damit nur wenige Aumlnderungen erfaumlhrt

432 Media-Type-Codierung

Ein junger Ansatz der Versionierung des Service bietet die Codierung in den Medien-typen wie zB JSON XML Text Fuumlr diese sind entsprechende Provider zum kom-fortablen Mapping vorhanden Zusaumltzlich koumlnnen eigene Medientypen erstellt werdendie bereits bestehende erweiternBsp applicationjson wird zu applicationabc+json erweitert

Der Vorteil dieses Ansatzes ist dass alle Anfragen an die selbe URL erfolgen DerMedientyp wird im Header der Anfrage mitgesendet so koumlnnen auch mehrere Typenmitangegeben werden und Praumlferenzen mitgeteilt werden Dieses Verhandeln des Me-dientyps zwischen Client und Server heiszligt Content Negotiation Es kann somit uumlberdas zugrundeliegende Datenformat zwischen den Versionen der REST-Schnittstelle un-terschieden werden was zum einen die Unterstuumltzung fuumlr aumlltere Clients sichert zumanderen die Schnittstelle flexibel haumllt Unterstuumltzt der Server den Medientyp nicht sowird ein HTTP-Statuscode 415 (Unsupported media type) zuruumlckgegeben

27

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 35: Bachelor-Thesis_Julian_Suleder_181348.pdf

4 Technologieevaluation

Einige Technologien und Standards unterstuumltzen diesen Ansatz bereits so auch JAX-RSEine Unterscheidung wird dabei uumlber die Annotation javaxwsrsConsumes an denService-Methoden vorgenommen

Abbildung 42 Die Versionierung der Schnittstelle hat keinen Einfluss auf die Pfadeder Ressourcen und Services

433 Ergebnis

Die Versionierung durch den Medientypen ermoumlglicht das Aushandeln der verwendetenSchnittstellen-Version was die Migration der Clients vereinfacht Als Framework fuumlrdie hybride Applikation wird nach Auswahl (Abschnitt 415) Ionic Framework inVerbindung mit AngularJS verwendet Dieses unterstuumltzt in der jetzt verfuumlgbarenVersion nur die unveraumlnderlichen Medientypen Daher wird fuumlr die Versionierung desREST-Services die URL-Codierung verwendet Die Komplexitaumlt der Schnittstelle istfuumlr den Entwickler zwar houmlher als bei einer Codierung uumlber den Medientypen kanndurch ein entsprechendes Konzept jedoch gering gehalten werden

28

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 36: Bachelor-Thesis_Julian_Suleder_181348.pdf

5 Entwurf

In diesem Kapitel ist der Entwurf des verteilten Systems dargestellt In Abschnitt 51wird zunaumlchst auf die Verteilung des Systems auf die verschiedenen Geraumlte und Netzeeingegangen In den Abschnitten 52 und 53 wird die Architektur des Services undder hybriden App dargestellt und erlaumlutert

51 SystemarchitekturDas System besteht aus der hybriden Applikation die auf den Smartphones der Nut-zer installiert ist und einem REST-Service der auf einem Webserver der HochschuleHeilbronn auf Anfragen der Clients wartet Die App kommuniziert uumlber eine sichereVerbindung mit dem Service Dieser behandelt alle Anfragen der Clients zur Registrie-rung und Deregistrierung Um Aumlnderungen an der Datenbasis vornehmen zu koumlnnenerhaumllt die Applikation nach Abschluss der Arbeit Zugriff auf das Personenverzeichnisder Hochschule Heilbronn Fuumlr die Dauer der Arbeit wird eine Datenbank fuumlr Testseingerichtet

Abbildung 51 Beispielhafte Verteilung der Systemkomponenten im Netzwerk DieUumlbertragung uumlber unsichere Netze ist immer verschluumlsselt Interne Net-ze sind durch einen Rahmen gekennzeichnet

29

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 37: Bachelor-Thesis_Julian_Suleder_181348.pdf

5 Entwurf

52 Architektur des Server-Backends

Abbildung 52 Schichten desServer-Backends

Die Architektur des Server-Backends gliedert sichin drei Schichten (vgl Abbildung 52) Die ersteSchicht bildet die Zugriffsschicht auf die Anwen-dung und wird durch den REST-Service repraumlsen-tiert Dieser nimmt die Anfragen der Clients anund wandelt die Eingabe sowie die Antworten desdarunterliegenden Services in den erwarteten Da-tentyp um Die Schicht repraumlsentiert daher denzustandslosen Stellvertreter des objektorientiertenService Die direkt darunterliegende Schicht ist derauf die Datenhaltung zugreifende Service Der Ser-vice beinhaltet die Logik die notwendig ist um dieAnfragen der daruumlberliegenden Schicht zu behan-deln und konsistente und valide Zustaumlnde in derDatenhaltung zu gewaumlhrleisten

Um den REST-Service nach dem in Abschnitt 431 vorgestellten Prinzip uumlber die URLversionieren zu koumlnnen werden grundlegende Funktionen der Schnittstelle im InterfaceTagService festgehalten (siehe Abbildung 53) Diese hat keine Abhaumlngigkeiten zuJAX-RS definiert aber die Eingabe und Ausgabe

Da das Verhalten aller Services bezuumlglich der Aktualisierung der Verknuumlpfung gleichist wird die gemeinsame Funktionalitaumlt in die Klasse DelegateTagService ausgela-gert Unter deren Benutzung muss ein REST-Service lediglich die Konvertierung vonEingabe und Ausgabe vornehmen und die Durchfuumlhrung der Aktualisierung delegierenSoll der Ablauf erweitert werden kann dies uumlber die vorgesehenen Einschubmethodenerfolgen

Das Interface NfcService der Service-Schicht definiert die Schnittstelle zwischen kon-kreten die Datenbasis veraumlndernden Implementierungen der Funktionalitaumlt und derZugriffsschicht Eine konkrete Instanz zum Service dieser Schicht wird dem Objektder Klasse DelegateTagService bei der Instantiierung mit der NfcServiceFactoryinjiziert

Die zentralisierte Instantiierung ermoumlglicht die Konfiguration und Austauschbarkeitder verwendeten Services und reduziert die Abhaumlngigkeiten zwischen den Schichten ImDiagramm ist angedeutet dass fuumlr unterschiedliche Datenhaltungen oder Zugriffsartendarauf jeweils konkrete NfcServices implementiert werden die die Abhaumlngigkeitenzur Datenhaltung aufloumlsen Fuumlr die Arbeit wurde beispielhaft der Zugriff auf einerelationale Datenbank uumlber Java Persistence API (JPA) und einen ObjectRelational-Mapper (ORM) realisiert

30

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 38: Bachelor-Thesis_Julian_Suleder_181348.pdf

5 Entwurf

Abbildung 53 Klassendiagramm Die Architektur des Server-Backends gliedert sichin Zugriffsschicht Service und Datenhaltung

31

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 39: Bachelor-Thesis_Julian_Suleder_181348.pdf

5 Entwurf

53 Architektur der hybriden AppDie Architektur der hybriden Applikation mit Phonegap und AngularJS wurde inden Abschnitten 262 und 261 allgemein beschrieben Dieser Abschnitt erlaumlutertden Aufbau der Web-App und Verwaltung der Ressourcen (Abschnitt 531) fuumlr eineErleichterung der Integration weiterer Module sowie die verwendeten Cordova-Plugins(Abschnitt 532)

531 Modularisierung und Erweiterbarkeit

In Ionic-Projekten ist initial die Sortierung der Ressourcen wie zB JavaScript-HTML- und CSS-Dateien nach Dateityp eingerichtet AngularJS ermoumlglicht die Tren-nung Modul-Definition von Controllern Konstanten und Navigation Als Folge wer-den diese im Projekt nach Modul-Funktionalitaumlt sortiert in einzelne Dateien aus-gelagert und in einem modulspezifischen Verzeichnis abgelegt Diese Separation ofConcerns (SoC) ist in Abbildung 54 veranschaulicht und vereinfacht die Integrationweiterer Module

Abbildung 54 Modellierung der Projektstruktur Die Trennung der Moduldefinitionvon Navigation Controllern Konstanten ist als gestrichelte Linie vi-sualisiert Abhaumlngigkeiten sind als gerichtete Kanten dargestellt

In Controller-Instanzen erzeugte Variablen sind nur in dessen SichtbarkeitsbereichScope genannt zugaumlnglich Beim Seitenwechsel wird der aktuelle Scope verworfen undeine neue Instanz des Controllers erzeugt Als Folge kann eine Seite des Registrie-rungsassistenten nicht auf die Variablen vorheriger Seiten zugreifen Um dennoch Fel-der austauschen zu koumlnnen wird ein modulweit verfuumlgbarer Datenspeicher definiert

32

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 40: Bachelor-Thesis_Julian_Suleder_181348.pdf

5 Entwurf

(vgl nfcregistrationservicejs) in welchen die Seiten Variablen belegen undabfragen koumlnnen Dieser Speicher wird bei der Erzeugung eines Controllers mit denbenoumltigten Konstanten eines Moduls injiziert

Abbildung 55 Alle Modul-Zustaumlnde sind uumlber das Menuuml erreichbar

Die Navigation besteht aus Zustaumlnden die ein Triplet aus einer HTML-Seite zur Dar-stellung einer URL und einem eindeutigen Namen fuumlr den Zugriff bilden Jeder Zu-stand eines Moduls muss durch Transitionen anderer Zustaumlnde erreichbar sein Durcheine dezentralisierte Navigation koumlnnen modulspezifische Navigationen den Naviga-tionsautomaten beliebig aber eindeutig erweitern Transitionen zwischen Zustaumlndenverschiedener Module sollten nicht vorhanden sein um zusaumltzliche Abhaumlngigkeitenzwischen eigenstaumlndigen Modulen zu vermeiden Das Zusammenfuumlhren aller Modul-Zustaumlnde erfolgt im Menuuml der Applikation (vgl Abbildung 55)

532 Cordova-Plugins

Durch eine Plugin-Architektur ermoumlglicht Cordova die Integration und Austausch-barkeit von Plugins fuumlr die Erweiterung des Zugriffs auf Geraumltefunktionen

Fuumlr die Nutzung des NFC-Sensors wird ein auf GitHub verfuumlgbares Plugin1 verwendetdas die Verfuumlgbarkeit des Sensors uumlber die reine Benutzung hinaus testen kann

Da Cordova grundsaumltzlich den Zugriff auf fremde Ressourcen sperrt (siehe Abschnitt25)wird ein Whitelist-Plugin2 fuumlr Cordova hinzugefuumlgt dass den Zugriff auf Ressourcender angegebenen Quellen erlaubt Dabei wird die CORS-Beschraumlnkung gelockert

1httpsgithubcomchariotsolutionsphonegap-nfc Das NFC-Cordova-Plugin stammt vonDon Coleman der mit Tom Igoe Author eines Anfang 2014 erschienen Buches [28] uumlber dieNutzung von NFC mit Arduino Android und Phonegap ist

2httpsgithubcomapachecordova-plugin-whitelist

33

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 41: Bachelor-Thesis_Julian_Suleder_181348.pdf

5 Entwurf

54 Kommunikation zwischen App und Server

Abbildung 56 Nach der Initiierung des Absendens wird zunaumlchst automatisch einOPTIONS-Request gesendet um CORS-Regeln abzufragen Der nach-folgende POST-Request enthaumllt die Benutzerdaten

Die Applikation ist bis auf das Absenden der Benutzerdaten vollstaumlndig offline nutzbarAlle Ressourcen wie zB JavaScript- oder HTML-Dateien sind in das Build-Artefaktintegriert Folglich kommunizieren App und Server nur beim Austausch der Benut-zerdaten der Registrierung und Deregistrierung der NFC-Karten Das Absenden wirddurch den Benutzer initiiert und fuumlhrt dazu dass die Applikation einen POST-Requestmit den Benutzerdaten bei der Registrierung zusaumltzlich der Karten-ID an den Ser-ver sendet (vgl Listing 51) Die CORS-Mechanismen fuumlhren zu einem automatischenAbsenden eines vorausgehenden OPTIONS-Requests an den Server Dieser antwortetmit den zugelassenen HTTP-Methoden Authentifizierungsmoumlglichkeiten und CORS-Headern um dem Client den Zugriff auf die Ressource zu signalisieren Erst wennder Client die Erlaubnis des Servers erhaumllt sendet er den eigentlichen POST-RequestDer Server antwortet unabhaumlngig vom Ergebnis der Aktion mit einer JSON-NachrichtDiese beinhaltet einen Statuscode und eine textuelle Nachricht die dem Benutzer an-gezeigt wird (vgl Listing 52)

1 rsquousertag rsquo rsquopassword rsquo rsquoabc123 rsquorsquousername rsquo rsquosnoopy rsquorsquouidrsquo rsquo11223344556677 rsquo

Listing 51 Die Benutzerdaten und ggf Seriennummer der NFC-Karte werden anden Server gesendet

1 rsquoresult rsquo rsquostatus rsquo 200rsquomessage rsquo rsquoFeedback -Message rsquo

Listing 52 Die Antwort des Servers enthaumllt einen Statuscode sowie eineNachricht fuumlr den Benutzer

34

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 42: Bachelor-Thesis_Julian_Suleder_181348.pdf

6 Implementierung und Ergebnisse

Auf Basis des in Kapitel 5 vorgestellten Entwurfs wurde ein funktionaler Prototyp fuumlrApp und Backend erstellt Die Applikation besitzt den vollen in Kapitel 3 definiertenFunktionsumfang und kann im Hochschulnetz fuumlr die Registrierung und Deregistrie-rung von NFC-Karten eingesetzt werden weil das Backend durch einen Build-Serverkontinuierlich uumlbersetzt und auf einem Server der Medizinischen Informatik betriebenwird

61 Prototyp der hybriden AppIm Folgenden wird die Realisierung der Registrierung (Abschnitt 611) und Deregis-trierung (Abschnitt 612) auf Seite der hybriden Applikation dargestellt

611 Registrierung

Die Oberflaumlche des implementierten Prototyps der Startseite des Registrierungsassis-tenten mit Hinweisen zum benoumltigten NFC-Sensor ist in Abbildung 61 dargestellt Derim Papierentwurf konzipierte modale Dialog waumlhrend der Erfassung des Sensorstatusmusste nicht umgesetzt werden da der Sensorstatus durch das verwendete Plugindirekt von der Plattform ausgelesen werden konnte

Abbildung 61 Startseite der Registrierung zum Test des Sensorstatus (links) und derKartenerfassung (rechts)

35

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 43: Bachelor-Thesis_Julian_Suleder_181348.pdf

6 Implementierung und Ergebnisse

In Listing 61 ist die Methode zum Testen des Sensorstatus dargestellt Diese bewirkteine Umleitung auf eine Fehlerseite wenn der Sensor nicht aktiviert ist Die Schnitt-stelle zum NFC-Plugin bildet das injizierte nfc-Objekt Die Methode enabled diesesObjekts erwartet zwei Methoden wobei die erste das Verhalten bei aktiviertem Sensorund die zweite das alternative Verhalten unter Beruumlcksichtigung des Grundes spezifi-ziert Ist der Sensor aktiviert wird keine Aktion durchgefuumlhrt und keine Umleitungvorgenommen Die Methode kann daher direkt vor der Nutzung des Sensors erneutaufgerufen werden um eine zwischenzeitliche Statusaumlnderung des Sensors erkennen zukoumlnnen

1 function checkSensor () 2 nfcenabled(3 function () 4 function (reason) 5 if (reason == rsquoNO_NFC rsquo) 6 $statego(rsquoappnfcRegistration -norsquo)7 else if (reason == rsquoNFC_DISABLED rsquo) 8 $statego(rsquoappnfcRegistration -disabled rsquo)9 else

10 $statego(rsquoappnfcRegistration rsquo)11 12 )13

Listing 61 Die Methode nutzt das NFC-Plugin um den Sensorstatus zubestimmen Alternative Zustaumlnde des Sensor fuumlhren zur Umleitungauf eine Fehler-Seite

Durch das Betaumltigen des Karte erfassen-Buttons im rechten Bild von Abbildung 61wird uumlber das NFC-Plugin ein Listener am NFC-Sensor registriert Listing 62 zeigtden Aufruf der entsprechenden Methode des nfc-Objekts Dem Aufruf dieses Blocksgeht eine erneute Verwendung der in Listing 61 vorgestellten Methode voraus DieMethode erwartet drei Funktionen die das Verhalten bei einer erkannten Karte dererfolgreichen und erfolglosen Registrierung des Listeners spezifiziert

Wird eine Karte erkannt so wird mit der ersten Methode die Seriennummer der Karteausgelesen und in eine lesbarere Hex-Repraumlsentation mit Trennzeichen1 umgewandeltDie so erhaltene Seriennummer wird im Service des Moduls abgelegt um sie nachdem Entfernen des Listeners und einer Weiterleitung zum Absendeformular nutzen zukoumlnnen (vgl Abschnitt 531) Die zweite Methode fuumlhrt bei erfolgreicher Registrierungzur Anzeige eines modalen Dialogs Dieser ist in Abbildung 62 dargestellt

1Die Bytes der Seriennummer werden durch einen Doppelpunkt getrennt Bsp11223344556677

36

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 44: Bachelor-Thesis_Julian_Suleder_181348.pdf

6 Implementierung und Ergebnisse

1 nfcaddTagDiscoveredListener(2 function (nfcEvent) 3 String uid = getFormattedUID(nfcEventtagid)4 NfcRegistrationServicesetUid(uid)5 removeListener ()6 $scopemodalhide()7 $statego(rsquoappnfcRegistration -submit rsquo)8 function () 9 $scopemodalshow()

10 function (reason) 11 removeListener ()12 $scopemodalhide()13 )

Listing 62 Die Methode nutzt das NFC-Plugin um die Seriennummer der Karteauszulesen Nach einer Umwandlung wird diese in den modulweitenDatenspeicher abgelegt

Die Oberflaumlche des implementierten Prototyps des modalen Dialogs zum Auslesen derSeriennummer und das Absendeformular ist in Abbildung 62 dargestellt Der Dialogenthaumllt Hinweise fuumlr die Registrierung Der Benutzer initiiert die Verknuumlpfung durchdas Ausloumlsen von Karte verknuumlpfen

Abbildung 62 Modaler Dialog zum Auslesen der Karten-Seriennummer (links) undAbsendeformular (rechts)

37

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 45: Bachelor-Thesis_Julian_Suleder_181348.pdf

6 Implementierung und Ergebnisse

Nach dem Ausloumlsen der Verknuumlpfung wird wie in Abschnitt 54 beschrieben eineAnfrage an den Server abgeschickt Die erhaltene Antwort wird dem Benutzer nachStatuscode farbcodiert (siehe Abbildung 63) in rot (erfolglos) oder gruumln (erfolgreich)unter den Eingabefeldern des Formulars dargestellt (siehe Abbildung 64) Ist dasFormular nicht vollstaumlndig ausgefuumlllt erfolgt aumlquivalent die Anzeige einer Meldung ingelb eine Anfrage wird nicht getaumltigt

Abbildung 63 Die Antwort des Servers wird dem Benutzer eine farblich hervorgeho-ben dargestellt

Der Datenspeicher des Registrierungs-Moduls (siehe Listing 63) besitzt nur das Feldfuumlr die Seriennummer der gelesenen Karte und wird in den Controller injiziert

1 angularmodule(rsquonfcregistration rsquo)2 service(NfcRegistrationService function () 3 var uid = 4 return 5 getUid function () return thisuid 6 setUid function (id) thisuid = id 7 clear function () thisuid = 8 9 )

Listing 63 Der Datenspeicher der Registrierung besitzt manipulierende undsondierende Methoden fuumlr den Zugriff auf die definierte Variable

612 Deregistrierung

Abbildung 64Formular der Dere-gistrierung

In Abbildung 64 ist das Formular fuumlr die Loumlsung der Verknuumlp-fung von Karten und Benutzerkonten dargestellt das dem derRegistrierung bis auf das fehlende Feld der Seriennummeraumlhnelt

Nach dem Ausloumlsen der Deregistrierung wird eine Anfrage anden Server abgeschickt Die erhaltene Antwort wird dem Be-nutzer nach dem in Abbildung 63 dargestellten Farbmustervisualisiert

Durch die Simplizitaumlt der Deregistrierung benoumltigt das Modulkeinen Service und besitzt nur einen navigierbaren Zustand

38

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 46: Bachelor-Thesis_Julian_Suleder_181348.pdf

6 Implementierung und Ergebnisse

613 Allgemeiner Aufbau und andere Inhalte

Der allgemeine Aufbau der Applikation entspricht dem Modul-Entwurf aus Abschnitt531 Einzig das Modul zur Nutzung der Ionic-Funktionen kam hinzu Die Zusammen-fuumlhrung aller Module ist in Listing 64 dargestellt

1 angularmodule(rsquohhnrsquo [rsquoionic rsquorsquonfcregistration rsquorsquonfcderegistration rsquo rsquohhnconstants rsquo])

Listing 64 Eingebundene Module der Applikation

Als uumlber die Ziele der Arbeit hinausgehende Inhalte wurden Seiten fuumlr Standardinhaltemobiler Applikationen realisiert Diese umfassen eine Seite mit den verwendeten Fra-meworks und Plugins der mobilen Applikation sowie deren Lizenzen Daruumlber hinauswurden Seiten fuumlr Impressum und Nutzer-Feedback erstellt die vor dem Produktiv-betrieb mit entsprechenden Inhalten ausgestattet werden muumlssen (siehe Abbildung65)

Abbildung 65 Menuuml der Applikation (links) Seite mit den verwendeten Frameworksund deren Lizenzen (Mitte) und einem Rumpf fuumlr das Impressum(rechts)

Um die Erweiterbarkeit der Modulstruktur zu testen wurde ein von Tomi Semet2geschriebenes Ionic-Modul (siehe Anhang A) integriert Die Integration wird in Ab-schnitt 714 dargelegt und diskutiert

2Auszubildender des Rechenzentrums der HHN httpswwwhs-heilbronndetomisemet

39

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 47: Bachelor-Thesis_Julian_Suleder_181348.pdf

6 Implementierung und Ergebnisse

62 Prototyp des Server-BackendsDas Server-Backend wurde nach dem in Abschnitt 52 abgebildeten Klassendiagramm(Abbildung 53) implementiert

Listing 65 zeigt einen Ausschnitt des REST-Service der Anwendung Das Behandelnder Requests der Clients beschraumlnkt sich auf des Nutzen des DelegateTagServiceund Umwandeln von dessen Antwort in entsprechende HTTP-Antworten

1 Path(10 nfc)2 public class TagServiceImplRest 3 TagService service = null4 public TagServiceImplRest () 5 service = new DelegateTagService ()6

7 POST8 Path(update)9 Consumes(applicationjson)

10 Produces(applicationjson)11 public Response updateTag(UserTagImpl user) 12 Result result = serviceupdateTag(user)13 return handleResult(result)14 15

16 private Response handleResult(Result r) 17 switch (rgetStatus ()) 18 case 200 19 return Responseok(r applicationjson)build ()20 case 400 21 return Responsestatus (400)entity(r)build ()22 default 23 return ResponseserverError ()entity(r)build ()24 25 26

Listing 65 Behandeln eines POST-Request fuumlr die Registrierung von NFC-Tagsdurch Benutzung des DelegateTagService

Listing 66 zeigt am Beispiel der Registrierung das Delegieren an einen injizierten Ser-vice mit anschlieszligender Umwandlung der Antwort in ein fuumlr die App aufbereitetesFormat Das Verhalten besitzt groszlige Aumlhnlichkeit zu Listing 65 ist jedoch komplettunabhaumlngig von Nachrichtenprotokollen oder verwendeten Technologien und ermoumlg-licht die Nutzung des Services mit jeder beliebigen Zugriffsschicht

40

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 48: Bachelor-Thesis_Julian_Suleder_181348.pdf

6 Implementierung und Ergebnisse

1 public class DelegateTagService implements TagService 2 constructor service -injection3 protected void handleUpdateTag(UserTag u) throws

NfcLinkException 4 serviceaddTag(ugetUsername () ugetPassword () ugetUid ())5

6 Override7 public Result updateTag(UserTag user) 8 Result result = null9 try

10 handleUpdateTag(user)11 result = new Result (200 Verknuumlpfung war erfolgreich)12 catch (NfcLinkException e) 13 result = new Result (500 egetMessage ())14 catch (IllegalArgumentException v) 15 result = new Result (400 Eingabe ist unguumlltig)16 return result17 18

Listing 66 Umwandlung der Service-Antwort in ein Result-Objekt nachDelegation an einen behandelnden Service Vorgehensweise istaumlquivalent fuumlr die Deregistrierung anzuwenden

Fuumlr den Zugriff auf die Datenbank wird durch Abstraktion nur das Verhalten imple-mentiert ohne darunterliegende Technologien kennen zu muumlssen Deren Spezifizierungerfolgt erneut durch Injektion mittels zentraler Instantiierung

1 public class NfcServiceDatabase implements NfcService 2 constructor service -injection3 Override4 public void addTag(String username String password String uid)5 throws NfcLinkException 6 User user = servicegetUser(username password)7 if (user = null) 8 Tag tag = servicegetTag(uid)9 if (tag = null)

10 throw new NfcLinkException(Tag bereits verknuumlpft)11 tag = servicecreateTag(uid)12 usersetTag(tag)13 servicestore(user)14 else 15 throw new NfcLinkException(Benutzername oder Passwort unguuml

ltig)16 17

Listing 67 Vorgehen bei der Registrierung unter Verwendung einer Datenbank

41

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 49: Bachelor-Thesis_Julian_Suleder_181348.pdf

6 Implementierung und Ergebnisse

63 SicherheitsmechanismenDie CORS-Mechanismen verhindern einen Zugriff auf Ressourcen nicht gelisteter Quel-len Das Whitelisting dieser Domains erfolgt in der Cordova-Konfigurationsdatei derApplikation (siehe Listing 68) Zusaumltzlich werden in der indexhtml (siehe Listing 69)der Anwendung die Content Security Policy (CSP)-Einstellungen im Header hinterlegtDa eventuell fuumlr die Applikation notwendige Skripte nicht lokal vorgehalten werdenmuumlssen die Restriktionen fuumlr Skript-Quellen gesetzt werden um XSRF-Angriffe vor-beugen zu koumlnnen Fuumlr den in Abschnitt 54 vorgestellten Kommunikationsfluss muumlssenalle Antworten des Servers uumlber einen Filter (siehe Listing 610) mit CORS-Headerndekoriert werden

1 ltaccess origin=gt2 ltaccess origin=tel launch -external=yesgt3 ltaccess origin=mailto launch -external=yesgt4 ltallow -navigation href=gt5 ltallow -intent href= gt

Listing 68 Whitelisting aller vertrauenswuumlrdiger Ziele und Quellen in derconfigxml der Applikation

1 ltmeta http -equiv=Content -Security -Policy content=default -src style -src rsquoself rsquo rsquounsafe -inline rsquo script -src rsquoself rsquo rsquounsafe -

inline rsquo rsquounsafe -eval rsquogt

Listing 69 Vertrauenswuumlrdige Quellen fuumlr Medien und Skripte muumlssen im Headerder indexhtml gesetzt werden

1 Provider2 public class AccessControlResponseFilter implements

ContainerResponseFilter 3 Override4 public void filter(ContainerRequestContext requestContext

ContainerResponseContext responseContext) throwsIOException

5 MultivaluedMap ltString Object gt headers = responseContext6 getHeaders ()7 headersadd(Access -Control -Allow -Origin )8 headersadd(Access -Control -Allow -Headers9 Authorization Origin X-Requested -With Content -Type)

10 headersadd(Access -Control -Expose -Headers11 Location Content -Disposition)12 headersadd(Access -Control -Allow -MethodsPOST OPTIONS)13

Listing 610 Antworten des Servers muumlssen uumlber einen Filter mit CORS-Headerndekoriert werden

42

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 50: Bachelor-Thesis_Julian_Suleder_181348.pdf

7 Fazit und Ausblick

In diesem Kapitel werden die Ergebnisse der Analyse des Entwurfs und der Entwick-lung diskutiert sowie Optimierungs- und Erweiterungsmoumlglichkeiten der Applikationin Form eines Ausblicks vorgestellt

71 DiskussionDas Ziel der Arbeit war das Entwickeln einer mobilen Anwendung zur Registrierungvon NFC-Tags fuumlr die Identifizierung von Personen Nach vorausgehender Analyseder Anforderungen (Kapitel 3) und verfuumlgbarer Technologien (Kapitel 4) sowie desErstellens eines Entwurfs (Kapitel 5) wurde die Applikation realisiert (Kapitel 6)Dieses Ziel wurde nach Auffassung des Autors erreicht

711 Analyse Frameworks fuumlr hybride Applikationen

Fuumlr die Umsetzung der hybriden Applikation wurde Ionic Framework ausgewaumlhltwelches im Zusammenspiel mit AngularJS und Phonegap nach den in Kapitel 3 aufge-stellten Anforderungen bestmoumlglich entsprach Die Analyse der Frameworks basiertedabei auf den Angaben der einzelnen Hersteller Sicherlich koumlnnte durch eine Test-Implementierung eine noch aussagekraumlftigere und zuverlaumlssigere Auswahl getroffenwerden Es ist jedoch anzuzweifeln dass der dabei gewonnene Mehrwert den entste-henden Aufwand in Einarbeitung und Umsetzung rechtfertigt

Eine Vielzahl der Loumlsungen wurde auf Grund aufkommender Kosten bereits fruumlhzeitigaus der Analyse ausgeschlossen Es bleibt fragwuumlrdig ob die Bereitstellung finanziellerMittel die Entwicklung der Applikation vereinfacht oder sogar bessere Ergebnisseerzielt haumltte Der zusaumltzliche Funktionsumfang der kommerziellen Loumlsungen ergab sichmeist aus Dienstleistungen wie zB Mobile Backend as a Service (MBaaS) oder 24h-Support welche fuumlr die Umsetzung an der Hochschule niedrige Relevanz besitzen

Die Anzahl auf dem Markt verfuumlgbarer Loumlsungen fuumlr hybride Apps steigt stetig Fuumlrdie Analyse wurden daher nur bereits stabil verfuumlgbare und verbreitete Frameworksbetrachtet Es bleibt abzuwarten welche Loumlsungen sich in naher Zukunft auf demMarkt etablieren werden Es ist jedoch anzunehmen dass Ionic Framework auf Grundseines Funktionsumfangs und der Community eines dieser Frameworks sein wird

712 Analyse JAX-RS Implementierungen amp JSON-Umwandlung

Als Implementierung des JAX-RS 20 Standards wurde RESTEasy ausgewaumlhlt DieEinfachheit in Einrichtung und Benutzung sowie die vielfaumlltige Verfuumlgbarkeit von Pro-vidern fuumlr Datenformate harmoniert mit der niedrigen Komplexitaumlt des zu entwickeln-den Service Die Auswahl basierte auf einer vergleichbaren Beispiel-ImplementierungDie uumlber den Standard hinaus funktionsreicheren Frameworks koumlnnten genauso gut

43

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 51: Bachelor-Thesis_Julian_Suleder_181348.pdf

7 Fazit und Ausblick

verwendet werden Es ist aber offensichtlich dass eine moumlglichst einfache Loumlsung ge-waumlhlt werden sollte um nicht kuumlnstlich zusaumltzliche Komplexitaumlt zu schaffen

713 Entwurf Server-Backend

Der Entwurf des Server-Backends ist so konzipiert dass der Wechsel der verwendetenTechnologie von Zugriffsschicht und Datenhaltung ohne umfassende Aumlnderungen ander Code-Basis durchfuumlhrbar sind Durch die dafuumlr eingefuumlhrten Abstraktionen ergibtsich zwar die angesprochene Flexibilitaumlt in der Wahl der Frameworks sowie eine erhoumlh-te Wiederverwendbarkeit der tieferen Schichten dennoch sinkt die Verstaumlndlichkeit desEntwurfs bei Erweiterung Zudem sei in Frage gestellt ob fuumlr weitere Funktionalitaumltder mobilen Applikation das bestehende Backend erweitert oder besser modulspezifi-sche Server-Anwendungen entworfen werden sollten die isoliert entwickelt betriebenund gewartet werden koumlnnen

714 Funktionaler Prototyp

Der funktionale Prototyp der Anwendung enthaumllt alle geforderten Funktionen zur Re-gistrierung und Deregistrierung von NFC-Karten und integriert daruumlber hinaus wei-tere in Applikationen enthaltene Inhalte wie zB eine Auflistung der verwendetenFrameworks und Plugins mit Lizenzen Die Applikation ist auf der Android-Plattformlauffaumlhig und kann innerhalb des Hochschulnetztes mit einer Testdatenbank getestetwerden Fuumlr den Produktivbetrieb muss jedoch die Uumlbertragung der Daten uumlber einesichere HTTPS-Verbindung konfiguriert werden um eine Uumlbermittlung im Klartextzu verhindern Im Rahmen der Entwicklung wurde auf die Konfiguration verzichtetDie Oberflaumlche der Applikation mit ihren Inhalten ist als Prototyp zu betrachten istnicht internationalisiert und erfuumlllt keine Usability-Normen1

715 Modularisierung des Prototyps

Im Folgenden wird der Erfolg der Modularisierung der Applikation diskutiert Hierfuumlrwurde ein von Tomi Semet2 Auszubildender des Rechenzentrums der HHN geschrie-benes Ionic-Modul (siehe Anhang A) integriert

Die Ressourcen des Moduls waren nach Typ der Dateien und nicht nach Funktio-nalitaumlt sortiert Diese mussten daher erst in die funktionsorientierte Modulstrukturgebracht werden (vgl Abb 71) Dafuumlr wurde ein Verzeichnis fuumlr alle Ressourcen desModuls angelegt in welches die HTML- und JavaScript-Dateien sowie verwendeteBilder integriert wurden Referenzen auf Bilder mussten korrigiert werden Das Modulwar zuvor nicht in ein Menuuml eingebettet gewesen sodass in den HTML-Seiten der Code

1DIN EN ISO 9241-110 beschreibt zB die Grundsaumltze der Dialoggestaltung2httpswwwhs-heilbronndetomisemet

44

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 52: Bachelor-Thesis_Julian_Suleder_181348.pdf

7 Fazit und Ausblick

minimal angepasst werden musste Die interne Struktur des Moduls mit ControllernNavigation und Moduldefinition konnte identisch uumlbernommen werden

Abbildung 71 Die Strukturaumlnderung bei der Integration des Moduls

Nach der Aufbereitung erfolgte die eigentliche Integration des Moduls Dabei wurdenalle JavaScript-Ressourcen in die indexhtml aufgenommen Zusaumltzlich musste dieReferenz auf das Personenverzeichnis in der Moduldefinition der Applikation ergaumlnztwerden sowie ein passender Menuumleintrag erstellt werden Fuumlr die Verwendung derTelefon- und E-Mail-Funktion des Smartphones mussten die Verweise unter Verwen-dung externen Applikationen in der configxml freigeschaltet werden

Die Integration des Moduls wirkt durch die zusaumltzliche Umstrukturierung komplexwar jedoch absehbar einfach Fuumlr die Integration des Moduls wurden insgesamt 8Zeilen Code hinzugefuumlgt sowie die Moduldefinition um den Modulnamen erweitert

72 AusblickVor einer realen Nutzung des Systems muumlssen der Datenschutz und andere organisato-rische und rechtliche Pflichten wie zum Beispiel das Telemediengesetz beruumlcksichtigtwerden Die Umsetzung der dort geregelten Pflichten durch die Entwickler wird vonden Betreibern der App-Stores erwartet Auch der Aufwand des Ausrollens in einenStore darf nicht unterschaumltzt werden Dieser kann durch die Umsetzung organisato-rischer Maszlignahmen zum automatischen Testen und kontinuierlichen Ausrollen derhybriden Applikation reduziert werden und ermoumlglicht gleichzeitig die effektive Ent-wicklung im Team

Eine Benutzerevaluation oder Gebrauchstauglichkeitsnormen entsprechende Umstruk-turierung der Anwendung ist ebenso denkbar wie ein Testbetrieb mit verschiede-nen Identifizierungssystemen Moumlglicherweise wird in naher Zukunft der NFC-Sensorfuumlr die iOS-Plattform nutzbar sodass die Applikation auch dort Anwendung findenkann

Mit zusaumltzlichen Modulen wie zB einem personalisierten Stundenplan oder der In-tegration des Speiseplans der Mensa gibt es nach Meinung des Autors einige Anreizedie Applikation zu erweitern und den Produktivbetrieb anzustreben

45

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 53: Bachelor-Thesis_Julian_Suleder_181348.pdf

8 Literaturverzeichnis

[1] ISO ldquoInformation technology ndash Telecommunications and information exchangebetween systems ndash Near Field Communication ndash Interface and Protocol (NFCIP-1)rdquo ISOIEC 180922013 International Organization for Standardization Gene-va Switzerland 2013

[2] NFC Forum ldquoNFC and Contactless Technologiesrdquo httpnfc-forumorgwhat-is-nfcabout-the-technology ndash Letzter Zugriff 16062015

[3] R T Fielding ldquoArchitectural Styles and the Design of Network-based Softwa-re Architecturesrdquo httpswwwicsuciedu~fieldingpubsdissertationtophtm 2000 ndash Letzter Zugriff 16062015

[4] The World Wide Web Consortium (W3C) ldquoCross-Origin Resource Sharing - W3CRecommendation 16 January 2014rdquo httpwwww3orgTRcors ndash LetzterZugriff 24072015

[5] D Schadow Java-Web-Security Sichere Webanwendungen mit Java entwickelnHeidelberg DpunktVerlag 1 ed 2014

[6] A Freeman Pro AngularJS Apress Media LLC 2014

[7] Apache Cordova ldquoAbout Cordovardquo httpscordovaapacheorgabout ndashLetzter Zugriff 16062015

[8] PhoneGap ldquoAbout the Projectrdquo httpphonegapcomabout ndash Letzter Zu-griff 16062015

[9] T Bosch S Scheidt and T Winterberg Mobile Web-Apps mit JavaScript Leit-faden fuumlr die professionelle Entwicklung Entwickler Press 2012

[10] Appcelerator Inc ldquoThe Appcelerator Platformrdquo httpwwwappceleratorcom ndash Letzter Zugriff 06072015

[11] Embarcadero Technologies Inc ldquoDas FireMonkey-Frameworkrdquo httpswwwembarcaderocomdeproductsrad-studiofiremonkey ndash Letzter Zugriff06072015

[12] Intel Corporation ldquoIntel XDKrdquo httpssoftwareintelcomen-usintel-xdk ndash Letzter Zugriff 06072015

[13] NativeScript ldquoBuild truly native apps with JavaScriptrdquo httpswwwnativescriptorg ndash Letzter Zugriff 06072015

[14] Sencha Inc ldquoCreate native-looking HTML5 apps using JavaScriptrdquo httpwwwsenchacomproductstouch ndash Letzter Zugriff 06072015

46

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 54: Bachelor-Thesis_Julian_Suleder_181348.pdf

8 Literaturverzeichnis

[15] WebMynd Inc dba Trigger ldquoTriggerio - The simplest way to build amazingmobile appsrdquo httpstriggerio ndash Letzter Zugriff 06072015

[16] Xamarin Inc ldquoMobile App Development amp App Creation Software - Xamarinrdquohttpxamarincom ndash Letzter Zugriff 06072015

[17] AppGyver Inc ldquoSupersonic Frameworkrdquo httpwwwappgyvercom ndash LetzterZugriff 06072015

[18] Famous Industries Inc ldquoFamous Enginerdquo httpfamousorg ndash Letzter Zugriff06072015

[19] Drifty Corporation ldquoIonic Advanced HTML5 hybrid Mobile App Frameworkrdquohttpionicframeworkcom ndash Letzter Zugriff 06072015

[20] The jQuery Foundation ldquoA Touch-Optimized Web Frameworkrdquo httpsjquerymobilecom ndash Letzter Zugriff 06072015

[21] Telerik ldquoKendo UI - Everything for building web and mobile apps withHTML5 and JavaScriptrdquo httpwwwtelerikcomkendo-ui ndash Letzter Zu-griff 06072015

[22] Asial Corporation ldquoOnsen UI - The Answer to Cordova UI Developmentrdquo httponsenio ndash Letzter Zugriff 06072015

[23] Apache Software Foundation ldquoApache CXF An Open-Source Services Frame-workrdquo httpcxfapacheorg ndash Letzter Zugriff 07072015

[24] Oracle Corporation ldquoJersey - RESTful Web Services in Javardquo httpsjerseyjavanet ndash Letzter Zugriff 07072015

[25] Red Hat Inc ldquoRESTEasyrdquo httpresteasyjbossorg ndash Letzter Zugriff06072015

[26] Restlet Inc ldquoRestlet Framework Build Web APIs in Javardquo httprestletcomproductsrestlet-framework ndash Letzter Zugriff 06072015

[27] Google Inc ldquoVersioning Your Applicationsrdquo httpdeveloperandroidcomtoolspublishingversioninghtml ndash Letzter Zugriff 12072015

[28] T Igoe and D Coleman NFC mit Android und Arduino near field communica-tion fuumlr Maker OrsquoReilly 2014

47

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 55: Bachelor-Thesis_Julian_Suleder_181348.pdf

Anhang

I

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 56: Bachelor-Thesis_Julian_Suleder_181348.pdf

A Ionic-Modul Personalverzeichnis

Das Ionic Modul ist fuumlr das Personalverzeichnis der Mitarbeiter und Professoren derHochschule Heilbronn konzipiert Es kommuniziert uumlber einen REST-Service mit demLDAP-Server der Hochschule Heilbronn

Das Modul besitzt zwei Ansichten wobei sich in der ersten Ansicht die Liste allerMitarbeiter der Hochschule mit Suchfunktion zur Filterung nach Vor- und Nachnamenfindet Durch Auswahl eines Mitarbeiters gelangt man zur Einzelansicht Dort ist dasbei der Hochschule hinterlegte Bild und die Kontaktdaten der Person hinterlegt

Durch die Auswahl der Telefonnummer oder E-Mail-Adresse erfolgt die Kontaktauf-nahme

Abbildung A1 Listen- und Personenansicht des Personalverzeichnisses

II

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis
Page 57: Bachelor-Thesis_Julian_Suleder_181348.pdf

Eidesstattliche Erklaumlrung

Ich erklaumlre hiermit an Eides statt dass ich die vorliegende Arbeit selbststaumlndig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe die ausfremden Quellen (einschlieszliglich elektronischer Quellen) direkt oder indirekt uumlbernom-menen Gedanken sind als solche kenntlich gemacht

(Ort Datum) (Unterschrift)

  • Abkuumlrzungsverzeichnis
  • Einleitung
    • Motivation
    • Ziele
    • Vorgehensweise und Struktur der Arbeit
      • Grundlagen
        • NFC - Near Field Communication
        • REST - Representional State Transfer
        • JAX-RS - Java API for RESTful Web Services
        • Hybride Applikationen
        • Sicherheitsprobleme hybrider Applikationen
        • Middleware-Frameworks
          • AngularJS
          • Apache Cordova Phonegap
          • Appcelerator
          • FireMonkey
          • Intel XDK
          • NativeScript
          • Sencha Touch
          • TriggerIO
          • Xamarin
            • UI-Frameworks
              • AppGyver
              • Famous
              • Ionic Framework
              • jQuery Mobile
              • Kendo UI
              • Onsen UI
                • REST-Frameworks
                  • Apache CXF
                  • Jersey
                  • RESTEasy
                  • Restlet Framework
                      • Anforderungsanalyse
                        • Kerngedanken der Applikation
                        • Nutzungskontext
                        • Funktionale Anforderungen
                        • Nichtfunktionale Anforderungen
                        • Initiale Gestaltungsloumlsung
                          • Papierentwurf der Registrierung
                          • Papierentwurf der Deregistrierung
                              • Technologieevaluation
                                • Frameworks fuumlr hybride Apps
                                  • Formulierung Muss-Kriterien
                                  • Auswertung Muss-Kriterien
                                  • Formulierung Soll-Kriterien
                                  • Auswertung Soll-Kriterien
                                  • Ergebnis
                                    • JAX-RS Implementierungen amp JSON-Umwandlung
                                      • Manuelle Umwandlung mit Hilfsklassen
                                      • Automatische Umwandlung mit Provider
                                      • Automatische Umwandlung uumlber JAXB
                                      • Alternativloumlsung mit Servlets
                                      • Ergebnis
                                        • Versionierung von App und Server-Backend
                                          • URL-Codierung
                                          • Media-Type-Codierung
                                          • Ergebnis
                                              • Entwurf
                                                • Systemarchitektur
                                                • Architektur des Server-Backends
                                                • Architektur der hybriden App
                                                  • Modularisierung und Erweiterbarkeit
                                                  • Cordova-Plugins
                                                    • Kommunikation zwischen App und Server
                                                      • Implementierung und Ergebnisse
                                                        • Prototyp der hybriden App
                                                          • Registrierung
                                                          • Deregistrierung
                                                          • Allgemeiner Aufbau und andere Inhalte
                                                            • Prototyp des Server-Backends
                                                            • Sicherheitsmechanismen
                                                              • Fazit und Ausblick
                                                                • Diskussion
                                                                  • Analyse Frameworks fuumlr hybride Applikationen
                                                                  • Analyse JAX-RS Implementierungen amp JSON-Umwandlung
                                                                  • Entwurf Server-Backend
                                                                  • Funktionaler Prototyp
                                                                  • Modularisierung des Prototyps
                                                                    • Ausblick
                                                                      • Literaturverzeichnis
                                                                      • Anhang
                                                                        • Ionic-Modul Personalverzeichnis

Recommended