Teknik och samhälle Datavetenskap Examensarbete 15 högskolepoäng, grundnivå Effektiv konstruktion av dataaggregeringstjänster i Java Effective construction of data aggregation services in Java Fredrik Andersson Simon Cedergren Malmqvist Examen: Kandidatexamen 180 hp Huvudområde: Datavetenskap Program: Datavetenskap & applikationsutv. Datum för slutseminarium: 1 juni 2015 Handledare: Kristina Allder Andrabedömare: Bengt Nilsson Sammanfattning Stora mängder data genereras dagligen av slutanvändare hos olika tjänster. Denna data tenderar att tillhandahållas av olika aktörer, vilket skapar en fragmenterad marknad där slutanvändare måste nyttja flera programvaror för att ta del av all sin data. Detta kan motverkas genom utvecklandet av aggregeringstjänster vilka samlar data från flera tjänster på en enskild ändpunkt. Utveckling av denna typ av tjänster riskerar dock att bli kostsamt och tidskrävande, då ny kod skrivs för flera projekt trots att stora delar av funktionaliteten är snarlik. För att undvika detta kan etablerade tekniker och ramverk användas för att på så vis återanvända mer generella komponenter. Vilka av dessa tekniker som är bäst lämpade och således kan anses vara mest effektiva ur ett utvecklingsperspektiv, kan dock vara svårt att avgöra. Därför baseras denna uppsats på vad som genom analys av akademisk litteratur kan utläsas som ett akademiskt konsensus. Innan denna uppsats påbörjades utvecklades en Java-baserad dataaggeringstjänst baserad på krav från ÅF i Malmö. Denna experimentella implementation har som syfte att samla in data från två separata tjänster, och tillgängliggöra denna på en enskild ändpunkt. Efter att implementationen färdigställts påbörjades arbetet på uppsatsen. Denna består av en litteraturstudie för att undersöka vilka tekniker och ramverk som akademisk forskning funnit bäst lämpad för användningsområdet. Vidare används resultaten från studien även för att analysera i vilken grad dessa korrelerar med de krav som ÅF presenterade inför den experimentella implementationen. Litteraturstudien visar på att de teknikmässiga val som gjordes av företaget i stor utsträckning korrelerar med de tekniker som akademisk forskning funnit bäst lämpade för användningsområdet. Detta innefattar bland annat OAuth 2.0 för autentisering, JSON som serialiseringsformat samt REST som kommunikationsarkitektur. Vidare visar denna litteraturstudie på en eventuell lucka inom den tillgängliga litteraturen, då sökningar kring specifika programvaror relaterade till området endast resulterar i en mindre mängd artiklar. Abstract Large quantities of data are generated daily by the end users of various services. This data is often provided by different providers, which creates a fragmented market where the end users have to utilize multiple applications in order to access all of their data. This can be counteracted by the development of aggregation services that gather data from multiple services to a combined endpoint. The development of these kinds of services does however run the risk of becoming costly and time-consuming since new code is written for several projects even though large portions of the functionality is similar. To avoid this, established technologies and frameworks can be utilized, thereby reusing the more general components. Which of the technologies are the best suited, and thereby can be considered the most effective from a development perspective, can however be difficult to determine. This essay is therefore based on what can be considered an academic consensus through analysis of literature regarding earlier reasearch on the subject. Before the writing of the essay began a Java-based data aggregation service was developed, based on requirements from the company ÅF in Malmö. The purpose of this experimental implementation is to gather data from two separate services, and make them accessible on a unified endpoint. After the implementation was finished, work on the essay began. This consists of a literature review to investigate what technologies and frameworks that has been found best suited for this area of application by academic research. The results from this study are also used to analyze the extent of the correlation between the results and the requirements presented by ÅF regarding the experimental implementation. The literature review shows that the choices made by the company largely correlates with the technologies that the academic research has found best suited for this area of application. This includes OAuth 2.0 for authentication, JSON as a serialization format and REST for communications architecture. The literature review also indicates a possible gap within the available academic literature since searches regarding specific pieces of software related to the subject only results in a small amount of articles. Innehåll 1 Inledning 1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 Metod 2.1 Metodbeskrivning . . . . . . . . . . . 2.1.1 Litteraturstudie . . . . . . . . 2.1.2 Experimentell implementation 2.2 Metoddiskussion . . . . . . . . . . . . . . . 2 2 2 7 7 3 Resultat 3.1 Litteraturstudie . . . . . . . . 3.2 Experimentell implementation 3.2.1 Kommunikation . . . . 3.2.2 Autentisering . . . . . 3.2.3 Serialisering . . . . . . 3.2.4 Datakällor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 9 9 10 11 12 4 Analys 4.1 Auktorisering och autentisering 4.1.1 Dokumentation . . . . . 4.1.2 Alternativ . . . . . . . . 4.2 Serialisering . . . . . . . . . . . 4.2.1 Format . . . . . . . . . 4.2.2 Parser . . . . . . . . . . 4.3 Kommunikation . . . . . . . . . 4.3.1 Arkitektur . . . . . . . . 4.3.2 Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14 15 17 17 17 19 20 20 21 . . . . . 22 22 22 22 22 23 5 Diskussion 5.1 Frågeställning . . . . . . . . . 5.2 Litteraturstudie . . . . . . . . 5.2.1 Sökning . . . . . . . . 5.2.2 Material . . . . . . . . 5.3 Experimentell implementation 6 Slutsatser och vidare forskning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1 Inledning 1.1 Bakgrund I dagens samhälle genereras dagligen stora mängder data av alla möjliga slag. Detta innefattar allt från bilder och videoklipp till chatthistorik och privatpersoners fysiska mätvärden. Olika typer av data tenderar att tillhandahållas av olika aktörer, vilket skapar en fragmenterad marknad där slutanvändare måste nyttja flera tjänster för att ta del av all sin data. Denna situation kan undvikas med hjälp av utvecklandet av programvara med uppgiften att kombinera data från flera källor och samla denna på en enskild ändpunkt. Konstruktionen av sådana aggregeringstjänster riskerar dock att bli både kostsamt och tidskrävande. Detta då helt ny kod skrivs för olika projekt trots att en omfattande del av konstruktionen riskerar att bli snarlik. För att undvika att liknande lösningar implementeras från grunden vid varje nytt projekt kan ramverk, programvaror, samt övriga etablerade tekniker inkluderas för att på så vis återanvända de mest vitala komponenterna i ett system. Detta innebär att kostnader kan hållas nere och att utvecklingsprocessen kan effektiviseras, då mindre mängd ny kod behöver skrivas. Att avgöra vilka av dessa återanvändbara komponenter som är att föredra kan dock anses problematiskt, då utbudet är stort och olika källor tenderar att presentera vitt skilda rekommendationer. Vilka av dessa källor som är mest pålitliga kan komplicera ytterligare, då exempelvis företag och privatpersoner inte nödvändigtvis delar uppfattning och målsättning. Detta gör att en studie av tillgänglig akademisk litteratur kring relevanta komponenter och tekniker är tillrådlig, för att på så vis utläsa en vetenskapligt grundad konsensus. 1.2 Frågeställning Syftet med detta arbete är att undersöka hur ett Java-baserat system som samlar data från ett flertal öppna APIer, vilka tillhandahålls av olika leverantörer, kan konstrueras på ett effektivt sätt. Med ”effektivt” menas i detta sammanhang att skrivandet av ny kod minimeras till fördel för användandet av existerande tekniker. En lösning på denna frågeställning kommer att nås genom besvarandet av tre frågor: 1. Vilka ramverk är möjliga att använda i systemets konstruktion? 2. Vilka ramverk anser tidigare akademisk forskning vara bäst lämpade för uppgiften? 3. Vad krävs av tredjeparts-aktörer för att underlätta aggregering av data? 1 2 Metod 2.1 Metodbeskrivning Vid arbetets början konstruerades en experimentell implementation i samarbete med ett externt företag vid namn ÅF; ett svenskt konsultbolag vilka bland annat är verksamma inom IT och mjukvaruutveckling1 . Syftet med att inkludera detta samarbete i uppsatsen är att undersöka hur en Java-baserad dataaggregeringstjänst kan konstrueras i praktiken och vilka tekniker ett företag anser vara att föredra. Därefter påbörjades uppsatsen, där den huvudsakliga forskningsmetoden utgörs av en litteraturstudie vars syfte är att identifiera relevant akademisk litteratur kring ämnet och på så vis ge insyn i vilka ramverk och tekniker som tidigare forskning funnit bäst lämpade för detta användningsområde. Det implementerade systemet jämförs sedan med resultaten från litteraturstudien för att undersöka vad som kunde gjorts annorlunda, och på vilka områden de båda är eniga om en teknik eller programvara. Nedan följer ytterligare redogörelser för den experimentella implementationen samt för den litteraturstudie som genomförs för att införskaffa material kring tidigare forskning inom ämnet. 2.1.1 Litteraturstudie Syfte Litteraturstudiens syfte är att hitta litteratur kring akademisk forskning inom ämnet, och således undersöka vilka tekniker och programvaror som denna forskning funnit bäst lämpade för det valda användningsområdet. Vidare används det resulterande materialet till att undersöka huruvida de beslut som fattats kring den tidigare genomförda experimentella implementationen kan betraktas som de mest effektiva eller ej, genom att jämföra de resulterande teknikerna från studien med de som användes i systemet. Avgränsningar På grund av problemområdets omfattning begränsas studiens fokus till att endast innefatta de delar i ett dataaggregeringssystem vilka kan anses ha störst inverkan på systemets funktionalitet och prestanda. Detta innebär att en uppdelning görs för att abstrahera systemet, vilket resulterar i att tre mer generella områden kan granskas individuellt. Dessa områden väljs då de omfattar en adekvat del av det avsedda systemet som helhet. Nedan följer de valda områdena: • Autentisering & auktorisering: protokoll och ramverk för autentisering och auktorisering. • Serialisering: format och parser-bibliotek för förmedling och hantering av data. • Kommunikation: tekniker och programvaror för hantering av kommunikation med klienter och externa datakällor. Studien grundas på akademisk litteratur utgiven av ACM och IEEE då de båda är väletablerade och erkända källor inom datavetenskapen. För att undvika att material uteblir 1 Om ÅF: http://www.afconsult.com/sv/Om-AF/Om-AF/ 2 på grund av felaktig filtrering används de tjänster som direkt tillhandahålls av ACM och IEEE, istället för nyttjandet av aggregerande sökmotorer så som Google Scholar. De filter som väljs utgörs av att endast tidskrifter och konferensartiklar tillåts som sökresultat, samt att dessa ska vara publicerade av ACM respektive IEEE. För att maximera tillgänglig data vid litteratursökningen appliceras inga filter för tillåtet tidsintervall. Vid val av relevanta artiklar prioriteras dock artiklar utgivna mellan åren 2010-2015, för att undvika att föråldrad teknik och programvara färgar de åsikter som materialet speglar. Artiklar utgivna tidigare än denna period anses endast vara acceptabla i de fall där forskningen bidrar med unika infallsvinklar på det behandlade området, vilka inte är baserade på en specifik programvara eller implementation. Endast teknik tillgänglig för industrin anses relevant och därmed frånses tekniker som saknar en beprövad implementation. Detta innebär att artiklar som presenterar nya tekniker undviks till fördel för de artiklar som analyserar etablerade sådana. I de fall då information söks om en specifik implementation eller produkt görs detta i officiell dokumentation för respektive produkt eller teknik. Vid granskning av specifika programvaror begränsas litteraturstudien till att endast fokusera på tekniker för programmeringsspråket Java. Detta för att möjliggöra en mer djupgående granskning av teknik för ett specifikt programmeringsspråk, i kontrast till att ytligt granska programvaror för flertalet programmeringsspråk. Valet av detta språk är ett direkt resultat av de krav som ÅF ställde på den experimentella implementationen. Tidigare sökningar kring autentisering och auktorisering klargjorde att OAuth är den enda teknik som erbjuder den funktionalitet systemet kräver, därför är denna studie avgränsad till att endast undersöka OAuth. Då systemet som avses vid arbetets frågeställning består av en webbtjänst vilken kan förmedla data till klienter på åtskilliga plattformar begränsas de granskade serialiseringsformaten till att bestå av JSON och XML. Detta då de utgör två av de mest populära formaten i samband med webbtjänster, vilket styrks av sökningar i databaser så som ProgrammableWeb [1] där antalet JSON- och XML-baserade tjänster visar sig vara mångfaldigt större än antalet tjänster som använder sig av binära- eller andra textbaserade format. Vidare innebär faktumet att de valda formaten är textbaserade att de även är plattformsoberoende, vilket leder till att resultatet kan anses lättare att generalisera. Sökning Sökning av relevant litteratur görs med sökmotorerna ACM DL och IEEE Xplore. Samtliga söktermer används i båda databaser för att på så sätt hålla det granskade området konsekvent mellan tjänsterna. Tabellerna nedan redogör för antalet träffar vid sökning och är indelade efter övergripande ämnesområde där Tabell 1 redogör för kommunikation, Tabell 2 redogör för serialisering, och Tabell 3 redogör för autentisering och auktorisering. Vidare är tabellerna uppdelade i kolumner vilka representerar de använda databaserna. Sökmetoden i IEEE Xplore skiljer sig från den i ACM DL och denna skillnad har uppmärksammats i tabellerna genom användandet av olika skiljetecken mellan söktermerna. Vid sökning i IEEE Xplore har termer separerats med ”>” för att indikera att följande uttryck används för att vidare filtrera resultatet från föregående sökterm. Vid användning av ACM DL separeras söktermer istället med kommatecken då sökningar genomförs med samtliga termer simultant. Detta då denna tjänst binder samman begrepp med kommandot ”AND” för att försäkra att alla efterfrågade termer hittas i varje träff. 3 Vid de tillfällen där antalet träffar understiger 70 undersöks samtliga resultat genom en granskning av titel samt nyckelord. De artiklar vars titel eller nyckelord korrelerar med det aktuella ämnet väljs sedan ut för en närmare inspektion, vilket innefattar en granskning av abstract, sammanfattning, samt resultat. Detta följs av en mer djupgående granskning i de fall där artikeln bedöms som lämplig för studien. Kriterierna för denna granskning består av att artikeln ska innehålla konkreta åsikter eller påståenden kring det aktuella ämnet, i kontrast till att endast lista tekniska specifikationer eller liknande fakta. Kravet på dessa åsikter och påståenden är att de kan styrkas med litteratur kring tidigare forskning, vilken genomgått peer-review, eller genom egenhändig forskning utförd av den aktuella artikelns författare. För de artiklar som anses lämpliga granskas referenslistan för att på så vis hitta ytterligare relevant litteratur. Även detta urval görs med ovan nämnda metoder, och vidare granskning av referenser utförs sedan rekursivt. Denna sökning samt filtrering resulterar i ett antal artiklar vilka i enlighet med kriterierna ovan bedöms som lämpliga för genomförandet av litteraturstudien. Detta slutliga urval redogörs för i Tabell 4. (a) ACM (b) IEEE Sökterm java java, jersey java, jax java, ”jax rs” java, rest java, restful java, restful, rest java, restful, rest, jersey java, servlet java, servlet, rest java, servlet, web java, servlet, rest, web java, servlet, rest, web, jersey jersey jersey, rest* jersey, rest jersey, restful Antal 29036 702 134 22 10465 311 223 22 835 332 779 312 11 13792 1533 1425 30 Sökterm java java >jersey java >jax java >”jax rs” java >rest java >restful java >restful >rest java >restful >rest >jersey java >servlet java >servlet >rest java >servlet >web java >servlet >rest >web java >servlet >rest >web >jersey jersey jersey >rest* jersey >rest jersey >restful Tabell 1: Kommunikation 4 Antal 18182 21 9 0 99 33 15 0 111 0 84 0 0 5250 117 27 1 (b) IEEE (a) ACM Sökterm serializ* serializ*, json serializ*, xml serializ*, xml, json serializ*, rest serializ*, restful serializ*, api serializ*, rest, api serializ*, api, web serializ*, ”web service*” serializ*, ”web 2.0” serializ*, format* serializ*, format*, data, web serializ*, compar* serializ*, compar*, format* json json, compar* xml xml, compar* xml, json xml, json, compar* xml, json, web, compar* Sökterm serializ* serializ* >json serializ* >xml serializ* >xml >json serializ* >rest serializ* >restful serializ* >api serializ* >rest >api serializ* >api >web serializ* >”web service*” serializ* >”web 2.0” serializ* >format* serializ* >format* >data >web serializ* >compar* serializ* >compar* >format* json json >compar* xml xml >compar* xml >json xml >json >compar* xml >json >web >compar* Antal 471 13 76 9 171 5 101 52 52 12 8 89 55 91 17 1396 175 15492 2021 690 72 66 Tabell 2: Serialisering 5 Antal 1261 7 56 5 6 0 10 0 2 20 0 42 14 209 7 112 18 13053 1079 61 14 7 (b) IEEE (a) ACM Sökterm auth* auth*, rest auth*, restful auth*, restful, rest auth*, rest, restful auth*, compar* auth*, vs auth*, compar*, vs auth*, vs, compar* auth*, oauth* auth*, web auth*, web , oauth auth*, oauth, web oauth* oauth*, compar* oauth*, vs oauth*, rest oauth*, pros oauth*, cons oauth*, ”oauth 2” Sökterm auth* auth* >rest auth* >restful auth* >restful >rest auth* >rest >restful auth* >compar* auth* >vs auth* >compar* >vs auth* >vs >compar* auth* >oauth* auth* >web auth* >web >oauth auth* >oauth >web oauth* oauth* >compar* oauth* >vs oauth* >rest oauth* >pros oauth* >cons oauth* >”oauth 2” Antal 11273 2871 60 42 42 1719 1641 382 382 62 5109 58 58 203 24 49 121 122 130 62 Antal 197365 602 42 11 11 21764 603 183 183 65 8227 28 28 71 2 0 10 0 0 63 Tabell 3: Autentisering Titel ”POAuth: Privacy-aware Open Authorization for Native Apps on Smartphone Platforms” ”ROAuth: Recommendation Based Open Authorization” ”Information Sharing and User Privacy in the Third-party Identity Management Landscape” ”A design of cross-terminal web system based on JSON and REST” ”Modeling RESTful Applications” ”REST client pattern” ”Is the cloud the answer to scalability of ecologies? Using GAE to enable horizontal scalability” ”RESTful Web service frameworks in Java” ”Federated Identity and Access Management for the Internet of Things” ”Characteristics of Scalability and Their Impact on Performance” ”OAuth Based Authentication and Authorization in Open Telco API” ”A security analysis of the OAuth protocol” ”Federated Identity Access Broker Pattern for Cloud Computing” ”OAuth Demystified for Mobile Application Developers” ”Design of a security mechanism for RESTful Web Service communication through mobile clients” ”Information Sharing and User Privacy in the Third-party Identity Management Landscape” ”A Comparison of Data Serialization Formats for Optimal Efficiency on a Mobile Platform” ”Principled Design of the Modern Web Architecture” ”Google App Engine Gets Ready For Business” ”Comparison between JSON and XML in Applications Based on AJAX” ”Analysis of the Efficiency of Data Transmission Format Based on Ajax Applications” ”Comparison of JSON and XML Data Interchange Formats: A Case Study” ”Latencies of Service Invocation and Processing of the REST and SOAP Web Service Interfaces” ”Performance analysis of ubiquitous web systems for SmartPhones” ”Performance evaluation of object serialization libraries in XML, JSON and binary formats” ”A Performance Comparison of Web Service Object Marshalling and Unmarshalling Solutions” Författare Nauman, Khan, Othman m. fl. Shehab, Marouf och Hudel Vapen, Carlsson, Mahanti m. fl. Niu, Yang och Zhang Schreier Upadhyaya Ramasahayam och Deters Hongjun Fremantle, Aziz, Kopecký m. fl. Bondi Liu och Xu Yang och Manoharan Reimer, Abraham och Tan Chen, Pei, Chen m. fl. Backere, Hanssens, Heynssens m. fl. Vapen, Carlsson, Mahanti m. fl. Sumaray och Makki Fielding och Taylor Charles Lin, Chen, Chen m. fl. Wang, Wu och Yang Nurseitov, Paulson, Reynolds m. fl. Aihkisalo och Paaso Hameseder, Fowler och Peterson Maeda Aihkisalo och Paaso Utgivningsår 2012 2011 2015 2014 2011 2014 2011 2011 2014 2000 2012 2013 2013 2014 2014 2015 2012 2000 2012 2012 2011 2009 2012 2011 2012 2011 Tabell 4: Resulterande material från litteratursökning 6 Referensnummer [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] 2.1.2 Experimentell implementation Detta avsnitt behandlar utvecklandet av den experimentella implementationen. Underrubrikerna redogör således för implementationens bakgrund, syfte samt begränsningar. Bakgrund Grunden för implementationen utgjordes av ett utvecklingsuppdrag vilket utfördes på ÅF i Malmö under våren 2015. Systemet som efterfrågades hade som huvudsaklig uppgift att agera kombinerad ändpunkt för data från två olika tredjeparts-tjänster, och avsågs därmed fungera som ett öppet API. Ett grundkrav för systemet var att kommunikation med Sonys tjänst Lifelog utgjorde en vital del i konstruktionen. Detta då tjänstens API skulle öppnas för allmän användning inom en snar framtid och en önskan från ÅF och Sony fanns om att undersöka potentiella användningsområden. Lifelog samlar in data kring användares fysiska aktivitet via armband som kopplas till smarta telefoner via Bluetooth, och möjliggör sedan uthämtning av denna data med hjälp av den dedikerade mobil-applikationen eller tidigare nämnda webbtjänst. Syfte Inkluderandet av den tidigare konstruerade experimentella implementationen i uppsatsen har som huvudsakligt syfte att bidra med insikt kring hur den typ av system som beskrivs i arbetets frågeställning kan konstrueras i praktiken, samt vilka programvaror och tekniker ett etablerat företag inom industrin anser vara de bäst lämpade för användning inom det valda ämnesområdet. Detta system utgör således en referentiell utgångspunkt för hur denna typ av system kan konstrueras på ett effektivt sätt. Begränsningar Då konstruktion av den experimentella implementationen förlades hos ÅF angavs vissa krav av dem. Krav på systemets övergripande arkitektur fastställdes till en programvara vars syfte var att tillhandahålla data från Lifelog och en ytterligare datakälla, samt hantera autentisering. Utöver krav på arkitektur erhölls även tekniska sådana, så som krav på val av programmeringsspråk och ramverk. Vissa krav resulterade i ytterligare, indirekta, krav då de innebar att endast en enskild teknik var ett gångbart alternativ. Exempelvis krävde ÅF att systemet skulle utvecklas i webbtjänst-ramverket Jersey samt autentisering-biblioteket Guja, vilket implicit resulterade i att systemet i sin helhet skulle skrivas i programmeringsspråket Java samt använda OAuth 2.0 för autentisering. Vidare föreslogs användandet av PaaS-tjänsten2 Google App Engine för hosting3 samt Jackson för hantering av serialisering. 2.2 Metoddiskussion Beslutet att använda de valda tillvägagångssätten för besvarande av arbetets frågeställning fastställdes då en kombination av dem kan anses vara det lämpligaste sättet att besvara de relaterade underfrågorna. 2 PaaS: Akronym för Platform as a Service. En tjänst vars syfte är att bistå en applikation med nödvändig infrastruktur så som en Internet-anslutning och hårdvara [28]. 3 Host: värddator, det system som kör programmet. 7 Det är dock möjligt att rikta viss kritik mot valet av litteraturstudie som primär forskningsmetod. Huvuddelen av denna kritik kan argumenteras vara faktumet att svar på den frågeställning som behandlas blir beroende av det specifika forskningsmaterial som finns att tillgå vid den slutliga analysen. Detta innebär att en felaktig, eller ofullständig, litteratursökning kan färga det slutliga resultatet och på så vis leda till en vinklad bild av det område som granskas. Gällande det praktiska genomförandet av sökningen går dessa problem sannolikt att motverka genom att använda sig av god metodik och en strukturerad sökprocess. Externa faktorer, så som problem hos använda databaser eller bristande tillgång till material, kan dock anses vara svårare att bemöta. I övrigt kan faktumet att det analyserade materialet riskerar att vara föråldrat, och på så vis ger en inaktuell uppfattning kring ämnet, bidra till att kvaliteten på slutresultatet blir lidande. Detta går dock till viss del att motverka genom att applicera lämpliga avgränsningar. För att undvika problematik relaterad till sökning och tillgång till relevant material hade användning av andra forskningsmetoder kunnat övervägas. Dessa hade exempelvis kunnat utgöras av intervjuer eller enkätundersökningar riktade till forskare inom det datavetenskapliga området. Dock hade detta presenterat ytterligare svårigheter; så som att genomföra intervjuer med ett representativt antal forskare inom den givna tidsramen. Vidare går det även att spekulera kring möjligheten att de forskare vars åsikter är att betrakta som relevanta i sammanhanget redan presenterat sina resultat i publicerade artiklar, varpå intervjuer eller undersökningar hade varit överflödiga i förhållande till en litteraturstudie. Då en omfattande del av frågeställningen utgörs av att undersöka akademiens åsikter och forskningsresultat kring ämnet kan en litteraturstudie därm argumenteras vara den metod att betrakta som bäst lämpad för att skapa en bred, generell uppfattning kring ämnet inom den givna tidsramen. Man kan därmed även argumentera för att en litteraturstudie hade varit tillräcklig för att inhämta de fakta och resultat som krävs för att besvara forskningsfrågorna då en utförlig, jämförande analys av det material som hittas vid en litteratursökning hade kunnat resultera i slutsatser kring frågeställningen, förutsatt att tillräcklig litteratur finns att tillgå. Dock hade en enskild litteraturstudie lett till behovet av en mer omfattande förstudie för att kartlägga aktuella och lämpliga tekniker, ramverk och protokoll. Det kan argumenteras för att detta även hade introducerat risker kring inbördes inkompatibilitet mellan dessa, samt riskerat att rikta litteratursökningen åt ett missvisande håll. Därför inkluderas även en experimentell implementation vilken konstruerats tillsammans med ett företag inom området, utifrån deras erfarenhet och expertis, och vilken används som referentiell utgångspunkt. Detta har till följd att logiska begränsningar tillämpas i studien och ger en insyn i vilka de kritiska delarna i ett sådant system är. Den experimentella implementationen ger på så vis mervärde till studien genom att tillföra en komparativ synvinkel, då de tekniker som valts av företaget i detta arbete således agerar motpol till de tekniker som anses bäst lämpade av akademisk forskning. 8 3 Resultat 3.1 Litteraturstudie Litteraturstudien resulterade i ett antal artiklar vilka behandlar de tre områden som i frågeställningen valts att representera det tänkta systemets kritiska delar. Ett större antal relevanta artiklar rörande autentisering har hittats under studiens gång, vilka samtliga huvudsakligen berör OAuth-protokollet samt vidareutveckling av detta [15] [4] [10] [16] [3]. Materialets fokus innebär att en kvalitativt inriktad analys har kunnat genomföras där protokollets styrkor och svagheter vägs mot varandra, för att undersöka huruvida protokollet lämpar sig för det tänkta systemet. Ett flertal artiklar kring serialisering fokuserar huvudsakligen på direkta jämförelser av prestanda mellan olika serialiseringsformat [22] [21] [25] [24] [23] [18]. Då denna aspekt betraktas som det mest kritiska av formatens egenskaper har detta möjliggjort utförandet av en kvantitativ analys där artiklarnas slutsatser jämförts för att utläsa en allmän konsensus kring ämnet. Ett antal artiklar innefattar även jämförelser mellan andra format än de som nämns i studiens avgränsningar, och i dessa fall togs endast resultaten för de format som tidigare bedömts som relevanta med i analysen. Endast ett mindre antal artiklar rörande parsers för det valda serialiseringsformatet har hittats, och av dessa är endast ”Performance evaluation of object serialization libraries in XML, JSON and binary formats” [26] att betrakta som faktiskt användbar. Detta då var och en av de övriga artiklarna endast inkluderat enstaka av de parsers som bedöms som lämpliga för arbetet, och en kvantitativ analys mellan dessa artiklar anses därför vara för opålitlig då experimentens förutsättningar skiljer sig i för stor omfattning. De artiklar som hittats kring arkitektur redogör huvudsakligen för implementationsförslag och designval vid konstruktion av en REST-baserad webbtjänst [6] [7] [5] [8]. Dessa belyser till en mindre del även skillnader och likheter mellan REST och SOA. Relevant litteratur om forskning kring programvara för plattform har visat sig vara i stort sett obefintlig. Konkret information kring detta område har endast kunnat utvinnas ur ”REST client pattern” [7], vilken huvudsakligen redogör för analyser kring REST-arkitektur, och således inte fokuserar på komparativ analys av plattformar för webbtjänster. Den information som kunnat utvinnas ur denna artikel går dock inte att verifiera, då inga andra studier finns tillgängliga för jämförelse. 3.2 Experimentell implementation Vid genomförandet av implementationen på ÅF konstruerades ett system där Jersey i kombination med Guja och Google App Engine utgör systemets fundament. Den programvara som utvecklades har som syfte att hantera användarkonton samt kommunikationen med yttre entiteter, exempelvis Lifelog. 3.2.1 Kommunikation Vid val av plattform för kommunikation hade ÅF önskemål om att använda Jersey tillsammans med Google App Engine. Därför är denna programvara utvecklad med ramverket Jersey. 9 Jersey Open Source-projektet Jersey är en referens-implementation av JAX-RS4 vilket låter utvecklare bygga webbtjänster i enlighet med REST [31]. REST är ett arkitekturellt designmönster för att skapa webbtjänster som minimerar både väntetider (en. latency) och nätverkskommunikation samt strävar efter att förenkla caching och möjligheten att bygga distribuerade system [19]. Jersey abstraherar hanteringen av förfrågningar och svar över HTTP genom Javaannoteringar så som @GET, @PUT, @POST etcetera, liksom hantering av HTTP-headers och URL-parametrar. Jersey tillhandahåller även stöd för filter vilket abstraherar implementation av roller i systemet och på så vis gör det möjligt att begränsa tillgång till resurser utifrån dessa [31]. Google App Engine Google App Engine är ett SDK och en PaaS-tjänst för bland annat Java-servlets. App Engine erbjuder automatisk och sömlös upp- och nedskalning av systemresurser; vid de tillfällen då endast ett fåtal förfrågningar görs till tjänsten allokeras färre resurser än vid de tillfällen då stora antal förfrågningar görs, vilket gör det lämpligt för hosting av RESTtjänster [32]. 3.2.2 Autentisering Då systemet kräver användarkonton för att kunna aggregera data från andra källor innebär det att användare måste autentisera sig så att de endast ges tillgång till den data de är tillåtna att ta del av. Token Ett token är ett objekt, i denna kontext en maskingenererad textsträng, som används för att identifiera en användare [33]. Vid nyttjande av tokens kan en tjänst erhålla tillgång till en resurs på ett mer kontrollerat sätt. Då ett token kan knytas till en enskild tjänst och användare kan dessa användas för både auktorisering och autentisering [12]. Ett token kan ogiltigförklaras och på så vis återkalla tillgång för individuella tjänster, utan att tvingas återkalla tillgång för samtliga sådana [13] vilket är fallet om användaren istället delar med sig av sina inloggningsuppgifter i klartext [13] [10]. OAuth 2.0 OAuth5 är ett protokoll för autentisering som genom tokens gör det möjligt att dela resurser mellan tjänster utan att dela användarnamn och lösenord [34]. Genom en federerad inloggning6 kan exempelvis Alice dela sina sina foton på en fotowebbtjänst med en digital framkallningstjänst utan att framkallningstjänsten får tillgång Alice lösenord. Istället delas ett token (en. access-token) som autentiserar Alice: 1. Alice ansluter till framkallningstjänsten. 4 Specifikation JSR 311 [29] och JSR 339 [30] RFC6749 [34] 6 Åtkomst av resurser på tjänst A genom auktorisering från tjänst B. 5 10 2. Alice väljer att logga in på framkallningstjänsten genom foto-webbtjänsten för att ge framkallningstjänsten tillgång till bilderna. 3. Framkallningstjänsten omdirigerar Alice webbläsare till foto-webbtjänsten. 4. Alice anger sitt användarnamn och lösenord för foto-webbtjänsten. 5. Foto-webbtjänsten returnerar en URL som pekar mot foto-webbtjänstens autentiseringsserver med en tillhörande auktoriseringskod. 6. Framkallningstjänsten validerar auktoriseringskoden hos foto-webbtjänsten genom den URL som mottogs; om den är giltig returneras en access-token och en refreshtoken. 7. Nu har framkallningstjänsten tillgång till Alice bilder utan att ha kännedom om hennes lösenord till foto-webbtjänsten. Guja Guja är ett bibliotek för Java utvecklat av ÅF för att abstrahera och underlätta implementation av OAuth 2.0 [35]. Guja stödjer Google App Engine samt federerad inloggning via Facebook utan vidare modifikation. Stöd för ytterligare tjänster implementeras med hjälp av mallar som tillhandahålls av Guja. 3.2.3 Serialisering Då systemets syfte i grunden är att agera mellanhand för förmedling av data mellan webbtjänst och klient behövs ett serialiserings-format för att möjliggöra att denna överföring sker på ett effektivt sätt. JSON JSON (JavaScript Object Notation) är ett textformat vilket primärt är konstruerat för att möjliggöra serialisering av strukturerad data samt datautbyte mellan applikationer [36]. Som namnet antyder bygger formatet på objekt-notation hämtad från JavaScript. Formatet är oberoende av plattform samt programmeringsspråk och är konstruerat för att vara lätt att läsa och tolka för både människor och maskiner [37]. Detta görs bland annat genom att göra formatet så fåordigt som möjligt. JSON bygger på två strukturer för representation av data [37]. Den första av dessa är nyckel/värde-par där varje värde identifieras med en unik nyckel. Detta benämns ofta som ett ”JSON-objekt”. Den andra är en ordnad lista av värden eller objekt där samtliga delar en övergripande, gemensam, nyckel. Denna struktur tenderar att benämnas som en ”JSON-array”. Jackson Jackson är en JSON-parser för Java som sömlöst tolkar JSON och omvandlar resultatet till POJOs7 [39]. Utöver JSON hanterar Jackson även andra typer av serialiseringsformat så som XML, CSV, Smile, CBOR, Avro och YAML. För JAX-RS stöds enbart JSON, Smile, XML och CBOR. 7 POJO (Plain Old Java Object) är benämningen av ett Java-objekt som representerar en entitet [38]. 11 3.2.4 Datakällor Den experimentella implementationen aggregerar data från två REST-baserade webbtjänster vilka båda tillhandahåller data relaterad till fysisk aktivitet. Lifelog Nedan följer en beskrivning av Sony Lifelog, en av de valda datakällorna för den experimentella implementationen. Beskrivning Lifelog valdes som den primära tjänsten för datainsamling då ÅF listade användandet av detta som ett av grundkraven för systemet. Lifelog är en tjänst som via smartphone-applikationer, smarta klockor och aktivitetsarmband samlar in data om enhetens användare [40]. Tjänsten loggar olika typer av fysisk aktivitet samt information kring vilka andra applikationer som körs på användarens smartphone. Insamlad data presenteras i Lifelog-applikationen för Android, eller via ett öppet REST-API. Autentisering Tjänsten hanterar autentisering genom OAuth 2.0 i enlighet med det flöde som beskrivs i tidigare avsnitt [41]. En livslängd för utfärdad access-token inkluderas vid lyckad autentisering och då denna tid passerat måste refresh-token skickas i utbyte mot en ny access-token. Kommunikation Tjänsten är konstruerad i form av ett REST-API på den första nivån av Leonard Richardsons mogenhetsmodell [42]. Användandet av paginering8 via hyperlänkar vid stora datamängder kan dock betraktas som ett inslag av den tredje nivån i mogenhetsmodellen. Tjänsten använder sig endast av HTTP-verbet GET vid anrop, och all kommunikation sker med hjälp av formatet JSON [41]. Healthgraph Nedan följer en beskrivning av Fitnesskeeper Healthgraph, en av de valda datakällorna för den experimentella implementationen. Beskrivning Till sekundär datakälla valdes webbtjänsten Healthgraph från företaget Fitnesskeeper. Tjänsten aggregerar data från flera olika tjänster och applikationer vilka registrerats som samarbetspartners, och tillåter sedan uthämtning av denna via samlade ändpunkter [43]. Insamlandet av varierad data leder till att information kring flera aspekter av användarens hälsa och fysiska aktivitet kan hämtas beroende på vilka enheter och tjänster som användaren nyttjar. Autentisering Healthgraph använder sig av en förenklad implementation av OAuth 2.0 för autentisering där refresh-tokens exkluderats och utfärdade access-tokens ges en obegränsad livslängd [43]. I övrigt följer autentiseringen, precis som Lifelog, det kommunikationsflöde som beskrivs i tidigare avsnitt. 8 Uppdelning av en datamängd i flera digitala, eller fysiska, sidor. 12 Kommunikation Healthgraph kan beskrivas som ett REST-API på den tredje nivån av Leonard Richardsons mogenhetsmodell [42]. Ett första anrop görs till en specifik ändpunkt varpå möjliga övriga resurser returneras i form av hyperlänkar [43]. Dessa resurser kan bestå både av den data som efterfrågats och av ytterligare hyperlänkar. På så sätt kan även en maskin traversera genom datan. Tjänsten har stöd för CRUD-operationer9 och använder därmed HTTP-verben GET, PUT, POST, DELETE och HEAD [43]. Samtlig kommunikation sker i formatet JSON. 9 Akronym för ”Create, Read, Update, Remove” vilket avser de operationer som kan utföras på tillhandahållen data. 13 4 Analys 4.1 Auktorisering och autentisering Vid hantering av personlig data är en viktig del att säkerställa att den endast är tillgänglig för de- eller dem den är avsedd för. Genom autentisering identifierar användaren vem han eller hon är, och genom auktorisering fastställs vilken data användaren har rätt att ta del av [12]. Följande avsnitt behandlar tekniker och system för auktorisering och autentisering av användare för den typ av system som avses i arbetets frågeställning. Följande sektion fokuserar primärt på OAuth då de sökningar som genomfördes i början av studien påvisade en brist på lämpliga alternativ. En relevant aspekt kring OAuth är möjligheten till federerad auktorisering. Denna typ av auktorisering benämns som trebent OAuth-auktorisering [44], vilket innebär att användare auktoriseras genom en tjänst de redan är registrerade hos, varpå denna tjänst intygar användarens identitet till det ursprungliga systemet. På så sätt undviks hantering av känsliga användaruppgifter på ursprungssystemet, så som lösenord. I sektion 4.1.1 behandlas hur trebent auktorisering även kan användas för autentisering. I kontrast till de vinster kring effektivitet som federerad auktorisering och autentisering OAuth erbjuder påvisar Vapen, Carlsson, Mahanti m. fl. [4] de integritetsrelaterade risker som federerad auktorisering medför. I studien kategoriseras tjänster som tillhandahåller federerad auktorisering (IDP, identity provider) utifrån vilken typ av data en tredjepartstjänst (RP, relying party) ges tillgång till. I studiens lägsta skala erhålls en RP tillgång till grundläggande information så som användarnamn och epost-adress samt rättighet att utföra handlingar på användarens konto, exempelvis hämta en bild från kontot. Högsta graden i studiens riskskala avser möjligheten för en RP att ta del av ovanstående rättigheter men även användarens personliga information10 , information om användarens vänner samt information om exempelvis ”likes” och andra tjänst-specifika handlingar som användaren utfört på IDP-tjänsten. Shehab, Marouf och Hudel [3] presenterar i sin studie ett system som analyserar de rättigheter en RP förfrågar av en IDP och utifrån resultatet av denna analys ger användare en rekommendation om huruvida förfrågan är rimlig i förhållande till den service som RP-tjänsten erbjuder. Ett system som detta skulle kunna ge råd för användare likt den klassificering Vapen, Carlsson, Mahanti m. fl. genomför i sin studie. Shehab, Marouf och Hudel argumenterar för att systemet de utvecklat minskar risken för användare att dela mer data än de är medvetna om, vilket Vapen, Carlsson, Mahanti m. fl. belyser som en brist i den nuvarande specifikationen av OAuth. De tjänster som används för tillhandahållande av data i implementationen hos ÅF kan klassificeras mellan den lägsta och näst lägsta graden i studien utförd av Vapen, Carlsson, Mahanti m. fl., då Healthgraph och Lifelog i egenskap som IDP endast delar grundläggande information samt data om fysisk aktivitet om respektive användare. Genom användandet av trebent OAuth-auktorisering minimeras insamlandet av data om användare, och även inräknat den data som tillhandahålls av datakällorna skulle en användare ej kunna knytas till en person genom annat än sin epost-adress. 10 Exempelvis religiös- och politisk åsikt 14 4.1.1 Dokumentation Chen, Pei, Chen m. fl. [15] belyser i sin studie att OAuth är ett protokoll utvecklat primärt för auktorisering på webbsidor, vilket stärks i den officiella dokumentationen [34]. Chen, Pei, Chen m. fl. hävdar i sin studie att OAuth på grund av otydlig dokumentation övergått till att även användas för autentisering. Dokumentationen för OAuth beskriver flertalet typer av implementation. Enligt Chen, Pei, Chen m. fl. används endast följande tre i praktiken: • OAuth 1.0 & OAuth 1.0a: vid användande av OAuth 1 finns endast ett möjligt sätt att implementera autentisering, se Figur 1a. • OAuth 2.0, implicit godkännande: vid användande av OAuth 2.0 kan ett implicit godkännande göras, se Figur 1b. Vid ett implicit godkännande överförs access tokens direkt till klienten och då OAuth 2.0, till skillnad mot OAuth 1, saknar stöd för signering av tokens möjliggör detta för en tredje part att kapa ett access token och återanvända för att förfalska en inloggning. Därför är implicit godkännande ej lämpligt för autentisering. • OAuth 2.0, godkännande via auktoriseringskod: vid användande av auktoriseringskod flyttas den sårbara delen av godkännandet från att överföras från server till klient till att överföras direkt från server till server, vilket gör det svårare för en tredje part att kapa det access token som utbytes, se Figur 1c. I systemet som utvecklats i samband med denna uppsats nyttjas denna typ av implementation. Otydlig dokumentation försvårar för utvecklare och gör autentisering- och auktoriseringsmekanismer sårbara vilket Chen, Pei, Chen m. fl. stärker i sin studie då de fann att 149 applikationer av totalt 600 använde OAuth varpå 59,7% av dessa var sårbara på grund av bristfällig implementation. Urvalet gjordes systematiskt och bestod av 300 applikationer för Android och 300 applikationer för IOS. Fremantle, Aziz, Kopecký m. fl. [10] hävdar att OAuth skalar väl, vilket innebär att prestanda och stabilitet bibehålls även under varierat och ökat användande [11], och det faktum att företag som Google, Facebook, Twitter och GitHub nyttjar protokollet för att skydda och möjliggöra tillgång till deras APIer kan ses som bevis för att OAuth är lämpligt i globala system med krav på hög tillgänglighet och prestanda. Backere, Hanssens, Heynssens m. fl. [16] påvisar dock i sin studie att OAuth ej följer de principer som REST främjar kring ”statelessness”, att klienten hanterar och anger all nödvändig data vid varje enskilt anrop i motsats till att servern lagrar denna data mellan anrop, då OAuth kräver att servern kan validera det token som används för auktorisering. Ramasahayam och Deters [8] påstår i sin studie att denna egenskap är avgörande för möjligheten att skala horisontellt över flera servrar placerade på fysiskt skilda platser. Då OAuth bygger på tokens för autentisering och auktorisering bör de aspekter som nämns i sektion 3.2.2 kring ämnet tas i beaktande. Vad som kunde deduceras kring OAuth vid konstruktion av systemet på ÅF stärkte flera av ovannämnda påståenden; att använda tokens underlättade utvecklingen då de svårigheter som rör säkerhet kring användaruppgifter i stora drag undviks, eftersom detta moment kan substitueras av trebent OAuth-autentisering. Detta kan även generaliseras 15 (a) Autentiseringsflöde i OAuth 1.0/1.0a (b) Autentiseringsflöde för OAuth 2.0 genom implicit godkännande (c) Autentiseringsflöde för OAuth 2.0 genom auktoriseringskod Figur 1: Autentiseringsflöden för OAuth 1.0(a) och 2.0, illustrerade av Chen, Pei, Chen m. fl. [15] 16 för många andra former av dataaggregeringssystem i de fall då minst en datakälla nyttjar OAuth. För att undvika många av de svårigheter som nämns ovan kring bristande dokumentation användes OAuth-biblioteket Guja vid implementation, vilket hanterade autentisering och auktorisering i systemet. 4.1.2 Alternativ Det finns en uppsjö alternativ till OAuth för att tillhandahålla autentisering- och autentiseringlösningar. I de sökningar som genomfördes vid studiens början tydliggjordes dock att kraven på systemet endast lämnade OAuth som ett adekvat alternativ. Övriga lösningar så som Kerberos och SAML tillför krav på XML-baserad kommunikation och dedikerade autentisering-servrar, i motsats till OAuth som lämnar val av serialiseringsformat öppet och som genom trebent autentisering låter användare autentiseras via en tredjepart-server. Vidare sker autentisering till systemets datakällor via OAuth 2.0 vilket gör ett separat autentiseringsystem redundant till trebent autentisering. 4.2 Serialisering Vid överföring av data kan valet av serialiseringsformat påverka både systemets prestanda och användarvänlighet. Detta då egenskaper så som storlek på serialiserad data bland annat kan resultera i längre överföringstider. Serialisering och deserialisering av data till och från serialiseringsformaten hanteras av en typ av mjukvara kallad ”parser”. Då integration av flera format kräver mer tid innebär detta även att implementation av lågpresterande format bör undvikas för att säkerställa effektivitet under utvecklingen. I delarna nedan redogörs för den analys som gjordes kring serialiseringsformat samt relaterad parser. 4.2.1 Format Inkluderade format Då JSON och XML kan betraktas som två av de mest använda formaten för serialisering i samband med webbtjänster begränsades litteraturstudien medvetet till att fokusera på dessa (se 2.1.1). Vidare innebar begränsningen till en REST-baserad webbtjänst även att binära format så som Googles Protocol Buffers [45] eller Apache Thrift [46] inte kunde betraktas som gångbara alternativ, trots att ett flertal studier har visat på att dessa tenderar att prestera betydligt bättre än textbaserade format vid överföring, samt generellt uppvisar mindre storlek för serialiserad data [18] [26]. XML (Extensible Markup Language) är ett märkspråk vilket bygger på SGML (Standard Generalized Markup Language) [47]. Formatet skapades för att förmedla strukturerad data över Internet i form av dokument vilka själva kan beskriva sin data, samt strukturen för denna, med hjälp av taggar. Strukturen i ett XML-dokument är på så vis mycket lik den hos ett HTML-dokument, och dokumenten är läsbara för både människor och maskiner. JSON (JavaScript Object Notation) är ett textbaserat format för datautväxling och bygger på objekt-notation hämtad från JavaScript [36]. Formatet skapades huvudsakligen för att förmedla serialiserad data i läsbar form, med så få redundanta tecken som möjligt. 17 Jämförelse Genom åren har ett flertal akademiska experiment genomförts med syftet att jämföra de två formatens effektivitet vid överföring, serialisering, samt deserialisering. Då båda formaten är plattformsoberoende har dessa experiment genomförts på en uppsättning olika plattformar och system. Lin, Chen, Chen m. fl. [21] och Wang, Wu och Yang [22] jämför de två formaten vid användande med AJAX-baserade applikationer, och resultaten från båda experimenten visar på att JSON på denna plattform uppvisar betydligt lägre tid för överföring av data mellan klient och server, samt deserialisering av denna på klientsidan. Den snabbare överföringshastigheten argumenteras vara ett resultat av den lägre storlek på serialiserad data som JSON uppvisar. Denna storleksskillnad grundar sig i faktumet att JSON använder en nyckel-värde-baserad struktur där varje dataobjekt har en associerad nyckel, och de två är åtskilda med ett skiljetecken. Då ett dataobjekt även kan bestå av en array innebär detta att flera värden kan representeras med hjälp av endast en nyckel [36]. Detta leder till betydligt färre redundanta tecken än vid användande av XML där varje värde kräver en start- och en sluttagg [21] [22] [47]. Då den typ av system som avses i arbetets frågeställning bör kunna förmedla data oberoende av plattform är det viktigt att även ta mobila enheter i beaktande vid utvärdering av serialiseringsformat. Sumaray och Makki [18] visar med sitt experiment på Android-baserade enheter att JSON uppvisar lägre tider än XML vid både serialisering och deserialisering på denna plattform. Vidare påvisas även här faktumet att data serialiserad med JSON-formatet använder sig av betydligt färre bytes vid lagring i jämförelse med samma data serialiserad som XML. Detta leder dem till slutsatsen att ”XML bör undvikas om ej nödvändigt, då JSON är ett överlägset alternativ”. Även Hameseder, Fowler och Petersons [25] experiment utfört på Apples Iphone påvisar att JSON tenderar att använda kortare tid för deserialisering och överföring över nätverk. Vid serialisering av data uppvisar dock XML ett tidsmässigt övertag på denna plattform. Hameseder, Fowler och Peterson belyser emellertid att experimentets resultat inte kan användas till att dra vidare slutsatser kring formatens effektivitet på andra plattformar, då de exakta tiderna för serialisering och deserialisering är beroende av de bibliotek som valts för parsing. Aihkisalo och Paaso [24] genomför jämförelser av serialiseringsformat vid användande av REST och SOAP vilka styrker påståendet att valet av parser är en av de mest kritiska faktorerna vid jämförelse av formaten. Vid förmedling av serialiserade POJO-objekt presterar JSON här tidsmässigt marginellt bättre än XML, och uppvisar en mindre storlek för serialiserad data. Denna storleksskillnad minskar dock vid överföring av binärdata, och de tidsmässiga skillnaderna skiftar även till att utgöra en marginell fördel för XML. Aihkisalo och Paaso påpekar själva att den parser som valts för hantering av JSON upplevs ha bristande prestanda vid serialisering och deserialisering vilket innebär att de fördelar som JSON tenderar att vinna på sina lägre överföringstider över nätverk går förlorade. Vidare påstår de även att förutsättningarna för experimentet inte speglar ett verkligt användningsscenario då det ett slutet, lokalt, nätverk används vilket även det motverkar de fördelar som en lägre storlek ger vid överföring. Som Hameseder, Fowler och Peterson och Aihkisalo och Paaso påpekar är de specifika tider som uppmäts för serialisering och deserialisering starkt beroende av de parsers som väljs för uppgiften. Nurseitov, Paulson, Reynolds m. fl. [23] påpekar även att faktorer så som belastning på det använda nätverket kan leda till att denna mätdata blir förvrängd. 18 Ett försök att motverka effekter från dessa typer av felkällor görs i denna uppsats med hjälp av inkluderandet av ett flertal experiment på flera olika plattformar, vilket möjliggör jämförelse av de två formatens tidsmässiga skillnader utan att fokusera på specifika, kvantitativa, resultat. Vid konstruktion av den experimentella implementationen inkluderades JSON som enskilt serialiseringsformat. Detta beslut fattades huvudsakligen då den allmänna uppfattningen hos utvecklare tenderar att vara att JSON presterar bättre än XML vad gäller överföringshastighet samt storlek vid serialisering. Granskning av den insamlade litteraturen visar på att detta antagande har stöd i den akademiska forskningen. Detta innebär att valet JSON över XML är att betrakta som relativt självklart vid konstruktion av en RESTbaserad webbtjänst, i de fall där det endast är möjligt att implementera ett enskilt format samt där prestanda är den huvudsakliga prioriteringen. Wang, Wu och Yang belyser dock att XML har styrkor inom andra områden än datautväxling, så som en bättre etablerad standard samt en förbättrad säkerhet. Vidare bör valet av format även anpassas efter de tjänster som systemet är tänkt att kommunicera med, för att undvika onödig konvertering mellan format. 4.2.2 Parser Då JSON i föregående stycke konstaterades vara det lämpligaste formatet för serialisering i denna typ av system utgör detta den främsta avgränsningen för valet av parser. Vidare innebär arbetets fokus på ett Java-baserat system att de möjliga valen av parsers avgränsas ytterligare. Mängden komparativ, akademisk, forskning kring detta ämne, med tidigare nämnda avgränsningar applicerade, är mycket begränsad. Bristen på relevant material innebär att en slutsats baserad enbart på akademisk litteratur är svår att fastslå. Detta huvudsakligen då prestanda vid serialisering och deserialisering kan anses vara de mest kritiska egenskaperna hos en parser, och jämförelse av prestanda via meta-analys inte är tillrådlig då variabler så som systemresurser och nätverkstrafik tenderar att variera mellan olika experiment [23]. Maeda [26] utför ett experiment där serialiserings- och deserialiseringstider hos bland annat ett flertal Java-baserade JSON-parsers jämförs. Resultaten visar på att biblioteket JsonSmart är den bäst presterande JSON-parsern vid deserialisering, medan Jackson är den bäst presterande JSON-parsern vid serialisering. Även Aihkisalo och Paaso [27] jämför ett flertal parsers, men med nästintill obefintlig överlappning med Maeda vad gäller valet av granskade parsers, med undantag för inkluderandet av Jackson. Detta innebär att en direkt jämförelse av artiklarnas kombinerade resultat blir opålitligt då förutsättningarna skiljer sig i för stor utsträckning. Faktumet att utbudet av tidigare forskning kring ämnet anses vara för litet hindrar möjligheterna att nå fram till en akademiskt grundad slutsats. Då Jackson inkluderas i Jersey [31] kan detta argumenteras ha varit det mest effektiva alternativet av parser för den experimentella implementationen ur ett implementationsperspektiv, då inkluderandet av detta ramverk vid konstruktion av systemet hos ÅF påskyndade utvecklingen markant. Jacksons prestanda i förhållande till andra alternativ kräver dock ytterligare forskning. Vidare tillåter Jackson även hantering av XML vilket även underlättar vid implementation av detta format [39] [31]. Huruvida detta val av parser kan anses vara det mest effektiva vid konstruktion av Java-baserade dataaggregeringstjänster överlag går dock ej att avgöra 19 på grund av det låga antalet relevanta artiklar. 4.3 Kommunikation För att systemet ska kunna genomföra utväxling av data med dess klienter krävs en plattform vilken kan hantera inkommande- och utgående kommunikation, vilken sker i enlighet med den arkitektur för webbtjänster som använts vid konstruktion. Plattformen utgörs av en programvara, eller ramverk, vilket abstraherar aspekter så som nätverkskommunikation för att på så vis effektivisera utvecklingsprocessen. 4.3.1 Arkitektur Två av de största arkitekturella inriktningarna vid konstruktion av en webbtjänst och dess funktionalitet är REST och SOA. Dessa bemöter båda problematiken kring datautväxling över större nätverk, men använder sig av markant åtskilda inriktningar vad gäller konstruktion och funktionalitet [42] [48]. Niu, Yang och Zhang [5] undersöker hur REST-principer kan förenkla utveckling av webbtjänster ur ett utvecklingsperspektiv. De påvisar att REST jämfört med RPC11 ökar möjligheterna för en utvecklare att återanvända kod i de fall då klienter kan nyttja en mellanhand för parsing. REST kan i dessa fall möjliggöra sömlös transformation till ett plattformsspecifikt objektformat, exempelvis JSON till POJO. Med dessa förutsättningar kan utvecklare fokusera på att utveckla affärslogik istället för plattformsspecifika serveranrop. Författarna konstaterar även att REST bibehåller låg koppling (en. coupling) mellan server och klient till skillnad mot RPC. Detta tillåter vissa förändringar på servern utan att påverka funktionalitet på klienten. Exempelvis skulle samtliga URLer på Healthgraph, med undantag av den bas-URI12 Healthgraph anger som statisk, kunna ändras utan att detta skulle påverka den experimentella implementationen i denna studie, då uthämtning av dessa URLer sker dynamiskt [49]. Ramasahayam och Deters [8] finner i sin studie att SOA-baserade system kan ha svårigheter att köras på PaaS-tjänser på grund av de långa körtider som SOA medför. Exempelvis skulle detta innebär problem i systemet på ÅF då de förfrågningar som tar mer än 30 sekunder att slutföra negligeras av Google App Engine. De krav som ställdes på systemet hos ÅF kring kommunikation var relativt simpla; systemet består ej av långa eller komplexa flöden av anrop, utan begränsas till ett autentiserings-anrop följt av ett anrop för uthämtning av data. I system som saknar avancerade flöden kan en REST-arkitektur anses mer lämplig då en sådan bibehåller låg eller ingen koppling mellan anrop [5] [6], och i många avseenden anses erbjuda högre prestanda i förhållande till tillgängliga systemresurser jämfört mot en SOA-baserad tjänst. En SOAarkitektur lämpar sig bättre i system som involverar mer invecklade procedurer, exempelvis vid transaktioner mellan banker eller bokningssystem, där en operation (t.ex. bokning av en biljett) sker över flertalet steg med flera olika val och flöden [48]. Att istället utveckla systemet hos ÅF som ett SOA-baserat system skulle ha varit tekniskt möjligt, men sett till vad som kan deduceras från denna litteraturstudie skulle det varit högst ineffektivt. Kompatibilitet med Google App Engine hade kvarstått som 11 12 Remote Procedure Call, exempelvis SOA https://api.runkeeper.com/user 20 ett problem och då samtliga datakällor är JSON-baserade hade detta introducerat parsing från XML till JSON då SOA är ett XML-baserat protokoll. I ”REST client pattern” [7] skriver Upadhyaya att stora företag så som Yahoo och Amazon fokuserar alltmer på att utveckla REST-tjänster snarare än SOA-baserade tjänster. Vidare påpekar författaren att detta har lett till bättre verktyg för utvecklare, och även fler och mer stabila ramverk. 4.3.2 Plattform För att dataagreggeringstjänster ska kunna hantera inkommande- och utgående dataförmedling krävs ett ramverk vilket hanterar detta genom att möjliggöra kommunikation i enlighet med den etablerade REST-arkitekturen [42] vilken i tidigare avsnitt konstaterades vara bäst lämpad för användning med den typ av system som avses i arbetets frågeställning. Sökandet efter material inom detta område påvisar en tydlig lucka inom tidigare akademisk forskning. Detta då inget material redogörande för resultat från komparativa studier kring Java-baserade ramverk för utveckling av webbtjänster har hittats vid litteratursökningen. Den artikel som hittades och kan anses någorlunda relevant redogör endast för översiktlig fakta kring flertalet ramverks uppbyggnad, och utelämnar därmed redogörelser för prestanda och andra kvantitativa aspekter [9]. Den resulterade litteraturen anses därmed vara för knapphändig för att möjliggöra fattande av en korrekt och akademiskt grundad slutsats kring den programvara som anses vara den bäst lämpade för detta användningsområde. Vid projektets början listade ÅF användandet av det REST-orienterade ramverket Jersey [31] som ett av grundkraven för systemet. Då ramverket har stöd för JAX-RS samt inkluderar parser-biblioteket Jackson [39] bidrar det därmed även med funktionalitet till andra områden än endast kommunikation. Upadhyaya [7] påstår även i ”REST client pattern” [7] att Jersey generellt anses använda få systemresurser, vilket är en kritisk egenskap hos programvara som används på PaaS-tjänster så som Google App Engine. Något material som styrker eller dementerar Upadhyayas påstående finns dock inte att tillgå. Med ovan nämnda egenskaper i åtanke kan Jersey argumenteras vara ett av de mest effektiva ramverken att inkludera i den experimentella implementationen i detta arbete, även frånsett det implicita kravet från ÅF. Detta då stöd för flertalet av de tekniker som granskats i detta arbete finns inkluderade i Jersey, så som Jackson [39]. Som tidigare nämnt påskyndade inkluderingen av detta ramverk utvecklingsprocessen av den experimentella implementationen markant, och påvisade klara fördelar med användningen av detta. Då akademiskt grundade slutsatser inte är möjliga att uppnå är det dock inte möjligt att avgöra huruvida Jersey presterar bättre prestandamässigt än alternativa ramverk. Därmed går det inte heller att påvisa huruvida Jersey kan anses vara det mest effektiva alternativet av plattform vid implementation för Java-baserade dataaggregeringstjänster överlag. 21 5 Diskussion 5.1 Frågeställning Då frågeställningen till en början upplevdes som bred applicerades en rad avgränsningar i ett försök att åtgärda detta. Dessa avgränsningar är huvudsakligen ett resultat av de krav som ÅF ställde på den experimentella implementationen, men bygger även till viss del på kunskap som förvärvats via sökningar genomförda före arbetets början. Det kan dock argumenteras för att frågeställningen trots dessa begränsningar är för omfattande. Detta då samtliga av de områden som berörs i arbetets analys kan utgöra grund för fristående, individuella studier. Samtidigt som de applicerade avgränsningarna på ett sätt har lyckats med att göra frågeställningen smalare, innebär de även att det granskade området blivit begränsat till en enskild typ av dataagreggeringstjänst. Detta gör att de slutsatser som konstaterats i litteraturstudien kan anses svåra att generalisera. Ett försök att motverka detta, och på så vis generalisera besvarandet av frågeställningen, har gjorts genom att granska serialisering, auktorisering och kommunikation individuellt vilket låter resultatet appliceras på andra system än det specifika system som redogörs för i detta arbete. 5.2 5.2.1 Litteraturstudie Sökning Valet att avgränsa sökandet av litteratur till endast IEEE Xplore och ACM DL visade sig mer problematiskt än väntat då de båda tjänsternas sökmotorer uppvisar vitt skilda beteenden vid specifika anrop. Inkluderandet av så kallade ”jokertecken” 13 resulterar i radikalt olika träffar mellan de båda tjänsterna, och i dokumentationen för ACM DL finns tvetydigheter kring hur jokertecken bör definieras. Detta har lett till att ett stort antal sökningar fått göras flera gånger för att försäkra sig om att de blivit korrekt utförda, men trots dessa upprepade försök skiljer sig det slutliga antalet träffar markant mellan de två databaserna. Huruvida denna diskrepans är ett resultat av sökmotorernas funktionalitet eller beror på skillnader i tjänsternas utbud är dock oklart. 5.2.2 Material Det faktum att arbetet begränsats till ett specifikt programmeringsspråk innebär att det studerade området blivit smalt och således lämnar en omfattande lucka i granskandet av tillgänglig teknik. Detta bidrar till komplikationer i form av otillräckliga mängder akademisk litteratur. Denna begränsning påvisar även ett av problemen med att inkludera- och anpassa avgränsningar efter en experimentell implementation i samarbete med en tredje part, vilken i detta arbete utgörs av ÅF. Detta då de krav som ställdes på programmeringsspråk och val av programvara bidragit till projektets smala fokus. Vid genomförandet av litteraturstudien blev det uppenbart att artiklar rörande specifika ämnesområden tenderar att behandla ämnet på likartade sätt, oavsett författare. Akademisk litteratur kring OAuth fokuserar till stor del på brister i protokollet eller hur det kan utökas till att bidra med ytterligare funktionalitet, medan akademisk litteratur 13 Tecken vilket av sökmotorn kan tolkas som vilket annat tecken, eller serie av tecken, som helst. 22 rörande serialisering främst handlar om olika jämförelser av prestanda. Övrig problematik kring denna typ av jämförelser är att konkreta slutsatser blir svåra att nå i de fall där de utförda experimenten inte har samma förutsättningar vad gäller programvara eller systemresurser. Akademisk litteratur om specifika implementationer och programvaror så som Jersey och Jackson är näst intill obefintlig. Sådan litteratur hade möjligen kunnat bidra till mer konkreta slutsatser kring frågeställningen och således även möjliggjort reflektioner kring val av teknik i den experimentella implementationen. Det kan argumenteras för att dessa luckor i litteraturstudien kunnat undvikas med hjälp av en mer utförlig förstudie kring tillgänglig litteratur, för att sedan anpassa frågeställningen till att inte fokusera på specifika implementationer och programvaror. Dock hade detta även resulterat i att bristerna i tidigare forskning inte hade redogjorts för i detta arbete. 5.3 Experimentell implementation Att implementera det experimentella systemet bidrog till möjligheten att undersöka hur ett system likt det som nämns i frågeställningen kan konstrueras i praktiken. Avsaknaden av ett referenssystem leder dock till att slutsatser om dessa komponenters effektivitet vid implementation enbart kan bedömas utifrån empiri. Tidsåtgång för genomförandet av implementationen bör även tas i beaktning då litteraturstudiens omfattning troligtvis hade kunnat breddas om den praktiska konstruktionen utelämnats. Detta då tiden för genomförandet av arbetet var begränsad, och exkluderande av detta moment hade troligen gett möjlighet att disponera tid till att undersöka ytterligare komponenter i en dataaggregeringstjänst. Genomförandet av den experimentella implementationen i samarbete med en extern aktör har bidragit med insikter i hur denna typ av system kan implementeras i en företagsmiljö, och leder på så vis till en kontrast gentemot de strikt akademiska infallsvinklar som granskats i litteraturstudien. Detta då inkluderandet av implementationen i uppsatsen som en referentiell utångspunkt och motpol till de tekniker som litteraturstudien funnit lämpliga medförde att rationella begränsningar tillämpades i studien och gav en insyn i vilka de kritiska delarna i ett sådant system är. Detta har dock lett till ett smalare område att granska, vilket medför både för- och nackdelar. Motargument till användandet av denna implementation kan dock vara att de programvaror och ramverk som förespråkas av ÅF inte är representativa för industrin överlag, och på så vis leder till en vinklad utgångspunkt. 23 6 Slutsatser och vidare forskning Litteratur grundad i akademisk forskning kring specifika implementationer och programvaror inom det granskade området tycks bristande, och leder till att konkreta slutsatser kring fråga 1 i studiens frågeställning är svåra att nå. Detta då en utförlig lista över samtliga möjliga tekniker inte går att sammanställa utifrån den tillgängliga akademiska litteraturen. I de fall där mängden relevant akademisk litteratur ansågs tillräcklig kan dock ett antal rekommenderade tekniker utläsas vilka utgjordes av OAuth 2.0 för autentisering, JSON som serialiseringsformat samt REST som kommunikationsarkitektur. Detta besvarar till viss grad fråga 2 i frågeställningen, men slutsatser kring rekommenderade programvaror går inte att fastslå utifrån resultatet av litteraturstudien. Förslag på vidare forskning utgörs därmed av komparativa studier mellan specifika programvaror och ramverk vilka används för konstruktion av webbtjänster och dataagreggeringssystem. De rekommenderade teknikerna tycks korrelera väl med de val som gjorts av företaget i studien. Dock saknas belägg för att påvisa en genuin korrelation mellan industrin och akademin, och på så vis utesluta ett sammanträffande. De tekniker som utgör svar på fråga 2 bidrar även till att besvara fråga 3 i frågeställningen, då tredjeparts-aktörer kan implementera dessa för att underlätta användande vid utveckling av nya tjänster. 24 Referenser [1] ProgrammableWeb. (2015). Programmableweb - apis, mashups and the web as platform. [Accessed May 18 2015], URL: http://www.programmableweb.com/. [2] M. Nauman, S. Khan, A. T. Othman, S. ulniza Musa och N. U. Rehman, ”Poauth: privacy-aware open authorization for native apps on smartphone platforms”, i Proceedings of the 6th International Conference on Ubiquitous Information Management and Communication, ser. ICUIMC ’12, Kuala Lumpur, Malaysia: ACM, 2012, 60:1–60:8, isbn: 978-1-4503-1172-4. doi: 10.1145/2184751.2184825. URL: http: //doi.acm.org/10.1145/2184751.2184825. [3] M. Shehab, S. Marouf och C. Hudel, ”Roauth: recommendation based open authorization”, i Proceedings of the Seventh Symposium on Usable Privacy and Security, ser. SOUPS ’11, Pittsburgh, Pennsylvania: ACM, 2011, 11:1–11:12, isbn: 978-1-45030911-0. doi: 10.1145/2078827.2078842. URL: http://doi.acm.org/10.1145/ 2078827.2078842. [4] A. Vapen, N. Carlsson, A. Mahanti och N. Shahmehri, ”Information sharing and user privacy in the third-party identity management landscape”, i Proceedings of the 5th ACM Conference on Data and Application Security and Privacy, ser. CODASPY ’15, San Antonio, Texas, USA: ACM, 2015, s. 151–153, isbn: 978-1-4503-3191-3. doi: 10. 1145/2699026.2699131. URL: http://doi.acm.org/10.1145/2699026.2699131. [5] Z. Niu, C. Yang och Y. Zhang, ”A design of cross-terminal web system based on json and rest”, i Software Engineering and Service Science (ICSESS), 2014 5th IEEE International Conference on, juni 2014, s. 904–907. doi: 10.1109/ICSESS.2014. 6933711. [6] S. Schreier, ”Modeling restful applications”, i Proceedings of the Second International Workshop on RESTful Design, ser. WS-REST ’11, Hyderabad, India: ACM, 2011, s. 15–21, isbn: 978-1-4503-0623-2. doi: 10.1145/1967428. 1967434. URL: http: //doi.acm.org/10.1145/1967428.1967434. [7] B. P. Upadhyaya, ”Rest client pattern”, i Industrial Electronics (ISIE), 2014 IEEE 23rd International Symposium on, juni 2014, s. 231–235. doi: 10.1109/ISIE.2014. 6864616. [8] R. Ramasahayam och R. Deters, ”Is the cloud the answer to scalability of ecologies? using gae to enable horizontal scalability”, i Digital Ecosystems and Technologies Conference (DEST), 2011 Proceedings of the 5th IEEE International Conference on, maj 2011, s. 317–323. doi: 10.1109/DEST.2011.5936602. [9] L. Hongjun, ”Restful web service frameworks in java”, i Signal Processing, Communications and Computing (ICSPCC), 2011 IEEE International Conference on, sept. 2011, s. 1–4. doi: 10.1109/ICSPCC.2011.6061739. [10] P. Fremantle, B. Aziz, J. Kopecký och P. Scott, ”Federated identity and access management for the internet of things”, i Secure Internet of Things (SIoT), 2014 International Workshop on, sept. 2014, s. 10–17. doi: 10.1109/SIoT.2014.8. 25 [11] A. B. Bondi, ”Characteristics of scalability and their impact on performance”, i Proceedings of the 2Nd International Workshop on Software and Performance, ser. WOSP ’00, Ottawa, Ontario, Canada: ACM, 2000, s. 195–203, isbn: 1-58113-195-X. doi: 10 . 1145 / 350391 . 350432. URL: http : / / doi . acm . org / 10 . 1145 / 350391 . 350432. [12] K. Liu och K. Xu, ”Oauth based authentication and authorization in open telco api”, i Computer Science and Electronics Engineering (ICCSEE), 2012 International Conference on, vol. 1, mars 2012, s. 176–179. doi: 10.1109/ICCSEE.2012.275. [13] F. Yang och S. Manoharan, ”A security analysis of the oauth protocol”, i Communications, Computers and Signal Processing (PACRIM), 2013 IEEE Pacific Rim Conference on, aug. 2013, s. 271–276. doi: 10.1109/PACRIM.2013.6625487. [14] T. Reimer, P. Abraham och Q. Tan, ”Federated identity access broker pattern for cloud computing”, i Network-Based Information Systems (NBiS), 2013 16th International Conference on, sept. 2013, s. 134–140. doi: 10.1109/NBiS.2013.23. [15] E. Chen, Y. Pei, S. Chen, Y. Tian, R. Kotcher och P. Tague, ”Oauth demystified for mobile application developers”, i Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’14, Scottsdale, Arizona, USA: ACM, 2014, s. 892–903, isbn: 978-1-4503-2957-6. doi: 10.1145/2660267.2660323. URL: http://doi.acm.org/10.1145/2660267.2660323. [16] F. D. Backere, B. Hanssens, R. Heynssens, R. Houthooft, A. Zuliani, S. Verstichel, B. Dhoedt och F. D. Turck, ”Design of a security mechanism for restful web service communication through mobile clients”, i Network Operations and Management Symposium (NOMS), 2014 IEEE, maj 2014, s. 1–6. doi: 10.1109/NOMS.2014.6838308. [17] A. Vapen, N. Carlsson, A. Mahanti och N. Shahmehri, ”Information sharing and user privacy in the third-party identity management landscape”, i Proceedings of the 5th ACM Conference on Data and Application Security and Privacy, ser. CODASPY ’15, San Antonio, Texas, USA: ACM, 2015, s. 151–153, isbn: 978-1-4503-3191-3. doi: 10. 1145/2699026.2699131. URL: http://doi.acm.org/10.1145/2699026.2699131. [18] A. Sumaray och S. K. Makki, ”A comparison of data serialization formats for optimal efficiency on a mobile platform”, i Proceedings of the 6th International Conference on Ubiquitous Information Management and Communication, ser. ICUIMC ’12, Kuala Lumpur, Malaysia: ACM, 2012, 48:1–48:6, isbn: 978-1-4503-1172-4. doi: 10.1145/ 2184751.2184810. URL: http://doi.acm.org/10.1145/2184751.2184810. [19] R. T. Fielding och R. N. Taylor, ”Principled design of the modern web architecture”, i Proceedings of the 22Nd International Conference on Software Engineering, ser. ICSE ’00, Limerick, Ireland: ACM, 2000, s. 407–416, isbn: 1-58113-206-9. doi: 10. 1145/337180.337228. URL: http://doi.acm.org/10.1145/337180.337228. [20] B. Charles, ”Google app engine gets ready for business”, English, Informationweek - Online, juni 2012. URL: http://search.proquest.com/docview/1022551001? accountid=12249. [21] B. Lin, Y. Chen, X. Chen och Y. Yu, ”Comparison between json and xml in applications based on ajax”, i Computer Science Service System (CSSS), 2012 International Conference on, aug. 2012, s. 1174–1177. doi: 10.1109/CSSS.2012.297. 26 [22] P. Wang, X. Wu och H. Yang, ”Analysis of the efficiency of data transmission format based on ajax applications”, i Information Technology, Computer Engineering and Management Sciences (ICM), 2011 International Conference on, vol. 4, sept. 2011, s. 265–268. doi: 10.1109/ICM.2011.199. [23] N. Nurseitov, M. Paulson, R. Reynolds och C. Izurieta, ”Comparison of JSON and XML Data Interchange Formats: A Case Study”, i CAINE, D. Che och D. Che, utg., ISCA, 2009, s. 157–162, isbn: 978-1-880843-73-4. URL: http://dblp.unitrier.de/rec/bibtex/conf/caine/NurseitovPRI09. [24] T. Aihkisalo och T. Paaso, ”Latencies of service invocation and processing of the rest and soap web service interfaces”, i Services (SERVICES), 2012 IEEE Eighth World Congress on, juni 2012, s. 100–107. doi: 10.1109/SERVICES.2012.55. [25] K. Hameseder, S. Fowler och A. Peterson, ”Performance analysis of ubiquitous web systems for smartphones”, i Performance Evaluation of Computer Telecommunication Systems (SPECTS), 2011 International Symposium on, juni 2011, s. 84–89. [26] K. Maeda, ”Performance evaluation of object serialization libraries in xml, json and binary formats”, i Digital Information and Communication Technology and it’s Applications (DICTAP), 2012 Second International Conference on, maj 2012, s. 177– 182. doi: 10.1109/DICTAP.2012.6215346. [27] T. Aihkisalo och T. Paaso, ”A performance comparison of web service object marshalling and unmarshalling solutions”, i Services (SERVICES), 2011 IEEE World Congress on, juli 2011, s. 122–129. doi: 10.1109/SERVICES.2011.61. [28] IDG. (2015). Språkwebb. [Accessed Mars 24 2015], URL: http://cstjanster.idg. se/sprakwebben/ord.asp?ord=platform-as-a-service. [29] H. Marc och S. Paul. (2009). Jax-rs: javaTM api for restful web services. [Accessed Mars 17 2015], URL: https://jsr311.java.net/nonav/releases/1.1/spec/ spec.html. [30] P.-G. Santiago och P. Marek. (2013). Jax-rs: javaTM api for restful web services. [Accessed Mars 17 2015], URL: http : / / download . oracle . com / otn - pub / jcp / jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf. [31] Oracle Corporation. (2015). Jersey - restful web services in java. [Accessed Mars 17 2015], URL: https://jersey.java.net/. [32] Google Inc. (2015). What is google app engine? [Accessed Mars 17 2015], URL: https://cloud.google.com/appengine/docs/whatisgoogleappengine. [33] W. Stallings och L. Brown, Computer Security: Principles and Practice, 2st. Pearson Education, 2011, isbn: 0132775069, 9780132775069. [34] D. Hardt, Ed., ”The oauth 2.0 authorization framework”, RFC 6749, okt. 2012, s. 1– 76. URL: http://tools.ietf.org/pdf/rfc6749. [35] M. Levin. (2009). Guja. [Accessed Mars 18 2015], URL: https : / / github . com / Wadpam/guja. [36] E. T. Bray, ”The javascript object notation (json) data interchange format”, RFC 7159, mars 2014, s. 1–12. URL: http://tools.ietf.org/html/rfc7159. 27 [37] JSON.org. (2015). Json. [Accessed Mars 18 2015], URL: http://json.org. [38] M. Fowler. (2015). Pojo. [Accessed Mars 18 2015], URL: http://www.martinfowler. com/bliki/POJO.html. [39] T. Saloranta. (2015). Jackson project home @github. [Accessed Mars 18 2015], URL: https://github.com/FasterXML/jackson. [40] Sony Corporation. (2015). Lifelog – innovativ androidTM -app för hälsoarmband från sony - sony smartphones (sverige). [Accessed April 20 2015], URL: http : / / www . sonymobile.com/se/apps-services/lifelog/. [41] ——, (2015). Get started | sony developer world. [Accessed April 20 2015], URL: https://developer.sony.com/develop/services/lifelog-api/get-started/. [42] J. Webber, S. Parastatidis och I. Robinson, REST in Practice: Hypermedia and Systems Architecture, 1st. O’Reilly Media, Inc., 2010, isbn: 0596805829, 9780596805821. [43] Fitnesskeeper, Inc. (2014). Healthgraph. [Accessed April 20 2015], URL: http:// runkeeper.com/developer/healthgraph/overview. [44] Twitter Inc. (2015). 3-legged authorization. [Accessed April 2 2015], URL: https: //dev.twitter.com/oauth/3-legged. [45] Google. (2015). Protocol buffers - google developers. [Accessed April 6 2015], URL: https://developers.google.com/protocol-buffers/. [46] Apache Software Foundation. (2014). Apache thrift - concepts. [Accessed April 6 2015], URL: https://thrift.apache.org/docs/concepts. [47] W3C. (2008). Extensible markup language (xml) 1.0 (fifth edition). [Accessed March 20 2015], URL: http://www.w3.org/TR/REC-xml/. [48] N. Josuttis, Soa in Practice: The Art of Distributed System Design. O’Reilly Media, Inc., 2007, isbn: 0596529554. [49] FitnessKeeper, Inc. (2015). Users. [Accessed April 9 2015], URL: http://runkeeper. com/developer/healthgraph/users. 28