• No results found

En prestandastudie på JSON-och XML-formaterad API-data

N/A
N/A
Protected

Academic year: 2021

Share "En prestandastudie på JSON-och XML-formaterad API-data"

Copied!
37
0
0

Loading.... (view fulltext now)

Full text

(1)

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 16hp | Datateknik

2017 | LIU-IDA/LITH-EX-G--17/054--SE

En prestandastudie på

JSON-och XML-formaterad API-data

A performance study on JSON- and XML-formatted API-data

Andreas Larsson

Handledare : Anders Fröberg Examinator : Anders Fröberg

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

(3)

Abstract

This paper aims to analyze the effects different data representation techniques have on the API generating the data, and the client receiving and processing it. For this purpose, the formats JSON and XML was chosen. In order to analyze the effects, an API was developed in order to generate realistic results. A simple client JavaScript website was created which requested the API for data in which it processed its response to a JSON- or XML-object depending on which test was conducted. The tests were separated in two sce-narios, where the used dataset was large or small respectively, represented in either JSON or XML. The client logged the time it took from the test’s beginning until all responses had been processed. The API-server measured the time it took from receiving the request until it was returned, as well as the system’s CPU- and virtual-memory usage.

The study found that JSON-formatted data overall resulted in a more efficient opera-tion. In all test cases the processing time for both the client and server were smaller for the JSON-formatted data. However, for small datasets, the study showed that the XML-formatted data used a marginally smaller portion of the system’s resources, although the JSON-formatted data was still processed quicker.

(4)

Sammanfattning

Den här rapporten avser undersöka effekterna olika representationsmetoder av samma data har på det API som genererar datan, samt klienten som tar emot och bearbetar den. För syftet har formaten JSON och XML valts. För att analysera påverkan på API:et och klienten utvecklades ett API för att testerna skulle ge realistiska resultat. En enkel klien-themsida i JavaScript utvecklades vars uppgift var att begära data från API:et som sedan bearbetades till JSON- eller XML-objekt beroende på vilket test som kördes. Testerna sep-arerades i två scenarion, där datamängden för de två scenarierna var stor respektive liten, representerat som JSON eller XML. Klienten loggade den tid det tog från att programmet startades till att samtliga svar hade bearbetats. API-servern mätte den tid det tog från att servern mottog klientens förfrågan till att ett svar var redo att returneras. Servern mätte också systemets CPU- och minnesanvändning.

Studien visade att JSON-formaterad data överlag resulterade i en mer effektiv operation. I samtliga testfall var bearbetningstiden för både klient och API-server lägre för JSON-formaterad data. Däremot visade testerna också att XML-JSON-formaterad data förbrukade en marginellt mindre andel av systemets resurser vid bearbetning av små datamängder. För samma testfall var dock bearbetningstiden av den JSON-formaterade datan fortfarande lägre.

(5)

Förord

Jag vill tacka SysPartner AB med medarbetare för att tagit mig under sina vingar och tillåtit mig att applicera min utbildning på något praktiskt. Samtliga medarbetare har ställt upp för att göra min närvaro bekväm och erbjudit kompetens inom områden som för mig varit obekanta. Jag vill särskilt tacka Marcus Hedberg som varit min handledare på företaget och avvarat sin dyrbara tid till att hjälpa mig komma igång och driva arbetet framåt. Jag vill dessutom tacka Simon Skogh för sin vänskapliga närvaro och erbjudandet av sin kompetens i de system som jag har arbetat med under arbetets gång. Jag vill också tacka Anders Fröberg som har agerat både handledare och examinator för mitt arbete. Anders har hjälpt mig att omformulera en idé till ett examensarbete, och har under arbetets gång bistått med den handledning som gjort mitt examensarbete möjligt.

Slutligen vill jag tacka Philip Johansson och Niklas Blomqvist som varit mina opponenter och erbjudit sina mycket hjälpsamma synpunkter och konstruktiv kritik på mitt arbete.

(6)

Innehållsförteckning

Sammanfattning iii Författarens tack v Innehållsförteckning vi Figurförteckning vii 1 Introduktion 1 1.1 Motivation . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 1 2 Bakgrund 2 2.1 Företaget . . . 2 2.2 Teknologier . . . 2 3 Teori 6 3.1 Datarepresentation . . . 6 4 Metod 8 4.1 Analys . . . 8 4.2 Design . . . 10 4.3 Representationsmetod . . . 11 5 Implementation 13 5.1 Front-end . . . 17 5.2 Representationsmetod . . . 17 6 Resultat 19 6.1 Scenario 1 - Stora datamängder . . . 19

6.2 Scenario 2 - Små datamängder . . . 20 7 Diskussion 22 7.1 Resultat . . . 22 7.2 Method . . . 24 7.3 Studie . . . 25 7.4 Källkritik . . . 26 8 Slutsats 27 8.1 Framtida arbete . . . 27 Bibliography 29

(7)

Figurförteckning

3.1 Samling (array) och objekt (object) i JSON. Källa: www.json.org . . . 7

4.1 Databasdiagram över hårdvarubudgeten. . . 10

4.2 Tabell över API:ets resurser. . . 11

5.1 Lista över användare från API:et. . . 14

5.2 Ett utdrag ur API:ets tidsberäkning. . . 15

5.3 Ett utdrag ur API:ets hårdvarubudget. . . 16

5.4 Intranätets vy av tidsrapportering. . . 17

5.5 Tabell över filstorlekarna som används av testerna. . . 18

5.6 Specifikation av den testmiljö som testerna exekverats på. . . 18

6.1 Resultat av klientens tester för scenario 1. . . 19

6.2 Stapeldiagram över klienttesternas resultat för scenario 1. . . 20

6.3 Resultat av serverns (API:ets) bearbetning av förfrågningarna för scenario 1. . . 20

6.4 Resultat av klientens tester för scenario 2. . . 20

6.5 Stapeldiagram över klienttesternas resultat för scenario 2. . . 21

(8)

1

Introduktion

1.1

Motivation

Isolerade datorsystem och tjänster har minskat både i antal och betydelse i takt med att mark-naden övergått och anpassats till service-oriented computing (SOC) [17, 13]. Denna övergång har kommit att ta integrering av IT-system från en fas där mjukvara endast var beroende av sin egen existens för att fungera, till att i allt större utsträckning göra sig beroende av andra applikationer och dess tjänster. Det handlar emellertid om att skapa program som utnyttjar webbtjänster (web services) för att överföra, identifiera och modifiera resurser som överförs med standardiserade kommunikationsmetoder över Internet [13]. En metodik för att imple-mentera web services är arkitekturen representational state transfer (REST, eller RESTful), som myntades av Roy Fielding år 2000 [7]. REST är en samling principer som appliceras under utvecklingen och användningen av webbtjänster, och arkitekturen har fått stort genomslag där den stod för 69 % av alla Web-API:er år 2014 [9]. Arkitekturen ställer inga krav på vilken metod man ska använda för att presentera informationen, varpå utvecklaren behöver göra ett medvetet val i vilken eller vilka representationsmetoder denne vill att erbjuda. Olika representationsmetoder påverkar dock både klient och server, och valet är därför inte alltid självklart.

1.2

Syfte

Det här arbetet kommer att studera en befintlig implementation av ett intranät på företaget SysPartner AB. Med SysPartners intranät som utgångspunkt kommer ett nytt intranät att utvecklas som senare kommer att användas för att utvärdera olika val av representationsme-toder och hur de presterar på server- och klientsidan. Syftet är att hitta en optimal represen-tationsmetod för SysPartners ändamål för att undvika att det bildas flaskhalsar när informa-tionen ska förberedas, skickas, tas emot och bearbetas.

1.3

Frågeställningar

1. Vilken av representationsmetoderna JSON och XML ger bäst prestanda för ett API och en klient med avseende på bearbetningstid och resursförbrukning?

(9)

2

Bakgrund

2.1

Företaget

Arbetet utförs hos SysPartner AB i Linköping. SysPartner är ett relativt ungt företag med sitt största kontor i Linköping, ett mindre kontor i Stockholm samt ett nystartat kontor i Norrköping. I Linköping har SysPartner i skrivande stund 20 anställda, och arbetar huvud-sakligen inom IT-sektorn där de utvecklar, driver och förvaltar företags IT-system.

SysPartner har ett intranät, som de själva underhåller, byggt på Drupal. Drupal är ett modulärt CMS-system (content management system) som tillåter användarna att flexibelt byta ut moduler för att syftet ska passa dem, vilket uppnås genom att låta modulerna kommu-nicera med varandra via ett underliggande gränssnitt (interface). Det som SysPartner har upptäckt är att nivån av standardisering i Drupal gör det väldigt smidigt att lägga till och ta bort moduler i intranätet, medan det å andra sidan är svårt att utveckla egen funktion-alitet och anpassa systemet utöver vad Drupal redan erbjuder. SysPartner vill därför på sikt byta ut sitt intranät, och genom att erbjuda datahantering med ett API skulle de mer flexibelt kunna experimentera med alternativa grafiska gränssnitt (front-end). Byggt på den idén uppstod syftet till arbetet, som kompletterats med en studie för att undersöka vilken representationsmetod som bäst lämpar sig att använda i API:et.

2.2

Teknologier

Hypertext transfer protocol (HTTP)

HTTP är ett protokoll för att överföra information mellan enheter på ett nätverk där enheter kan skicka förfrågningar (requests) till en annan enhet som kommer att returnera ett med-delande. Den enhet som begär information kallas i regel för klienten, och den besvarande enheten för servern. En förfrågan innehåller bland annat information om vilken operation klienten avser göra på den resurs som URL:en (Uniform Resource Locator) pekar på. Ett urval av dessa operationer är GET, PUT, POST och DELETE [16]. När en server svarar på en för-frågan kommer meddelandet bland annat innehålla en statuskod som indikerar hur servern tolkade förfrågan [16]. Statuskoden kan bland annat indikera att förfrågan bearbetades med

(10)

2.2. Teknologier

lyckat resultat (statuskod 200), eller om servern inte kunde finna den resurs som begärdes (statuskod 404).

Representational state transfer (REST)

REST är en arkitektur som begränsar utformningen och användningen av webbtjänster för att göra systemet skalbart och tillgängligt [13]. Syftet med REST är att göra systemet simpelt och enbart utnyttja grundläggande kommunikationstekniker. Genom att utveckla och använda systemet med minimala och grundläggande tekniker förebygger man behovet av speciell mjukvara för att använda tjänsten. För kommunikation förespråkar REST-arkitekturen användning av tillståndslös HTTP för att möjliggöra åtkomst med det enda kravet på Inter-netuppkoppling, vilket 53% av jordens befolkning innehar [8].

REST är alltså en arkitektur med principer som begränsar ett system för att det ska upp-fylla kraven som Roy Fielding presenterade i sin avhandling. Några av de kraven som Roy Fielding presenterade följer nedan.

REST-arkitekturens viktigaste principer

Null style

Grundläggande för utveckling i enlighet med REST-arkitektur är att systemets behov finns specificerade. Dessa behov beaktas under utvecklingen av systemet och begränsningarna appliceras successivt på ett sätt som påverkar systemet beteende i enlighet med REST:s principer [7].

Client-Server

Hela idén med REST är att det finns en klient som kommunicerar med en tjänst som kan bestå av en eller flera servrar. För att främja systemets skalbarhet, portabilitet och tillgäng-lighet oberoende av plattform separeras datahantering från användargränssnittet [7]. Detta tillåter de olika delarna i datahantering och användargränssnittet att utvecklas oberoende av varandra.

Stateless

REST-baserade system är tillståndslösa och bygger på tillståndslös HTTP. Det innebär att samtliga förfrågningar som sker från en klient till en server inte påverkas av de olika till-stånd som en klient kan befinna sig i [7]. Samtliga förfrågningar måste innehålla all informa-tion som är nödvändig för att servern ska kunna identifiera och returnera data, och servern kommer inte att beakta inom vilket tillstånd eller sammanhang klienten skickar sina för-frågningar. Kontrollen för vilka förfrågningar som ska skickas beroende på vilken position i gränssnittets hierarki användaren befinner sig i hamnar således på användarens gränssnitt, och inte på servern. Till exempel så kommer inte servern att beakta vad användaren tidigare begärt för resurser, eller vilken sida i det grafiska gränssnittet som användaren befinner sig i, när servern tolkar användarens förfrågningar.

Uniform Interface

Som nämnt ovan krävs det av klienten att förfrågningar innehåller all information för att unikt kunna identifiera resurser, vilket är en av de mest grundläggande av principerna i REST-arkitekturer. En resurs är information från servern som gjorts tillgänglig via ett en-hetligt gränssnitt (uniform interface) och som identifieras av en URI (uniform resource identifier). Den praxis som appliceras på gränssnittets design och användning handlar om att främja

(11)

2.2. Teknologier

identifiering av resurserna, manipulering av resurserna och låta resurserna vara självförk-larande. Till exempel så binder man en viss resurs till en logisk och relevant URI för att göra URI:en självförklarande. Tillgång till resurserna ges med hjälp av de inbyggda metoderna i HTTP: GET, PUT, POST och DELETE. Dessa appliceras i HTTP-paketet som pekar på en URI.

GET

URI Statuskod Beskrivning

syspartner.se/api/v1/users/ 200, 404 Returnerar en lista över användare.

syspartner.se/api/v1/users/123/ 200, 404 Returnerar detaljerad vy över en specifik användare unikt identifierad av "123".

PUT

URI Statuskod Beskrivning

syspartner.se/api/v1/users/123/ 200, 400, 404 Modifierar användaren identifierad av "123" enligt den information som fanns i klientens förfrågan. POST

URI Statuskod Beskrivning

syspartner.se/api/v1/users/ 201, 400, 404 Skapar användaren enligt den information som fanns i klientens förfrågan.

DELETE

URI Statuskod Beskrivning

syspartner.se/api/v1/users/123 204, 404 Raderar användaren identifierad av "123". Tabell 3.1: Exempel på metoder att anropa till ett API.

Django REST framework

Django REST framework, hädanefter kallad Django REST, är ett ramverk som bygger på Django Web Framework. Ramverket är skrivet i Python och erbjuder mer inbyggd funk-tionalitet än många andra ramverk. Det finns även möjlighet att lägga till extra funkfunk-tionalitet via tillägg om man är i behov av något som inte redan finns inbyggt i ramverket. Django Web Framework erbjuder skalbara, säkra och snabba grunder att webbutveckla i [2], och Django REST har anpassat ramverket för att utveckla API:er [4]. Båda ramverken är mycket väl dokumenterade och gratis med öppen källkod.

Django Views

Enligt allmän accepterad etikett utvecklas serverns interface i en fil kallad "views.py". Django erbjuder inbyggd funktionalitet för att utveckla views, som är funktioner som tar emot och returnerar webbförfrågningar. Här finns den logik som bearbetar en klients förfrågan och slutligen returnerar ett svar tillbaka, oavsett om det det är en hemsida, rådata, bild eller annan information. För arbetets syfte kommer enbart rådata att returneras, och hur rådatan ska se ut är vad som arbetet går ut på att utvärdera.

Django Models

Django Models är ett kraftfullt verktyg som används för att inom servern representera och lagra data. Django Models är ett ORM-verktyg (object-relational mapping) som representerar databastabeller som interna klasser, vilket underlättar serverns datalagring eftersom utveck-laren tillåts arbete med objekt istället för att exekvera ofiltrerade databasfrågor (queries).

(12)

2.2. Teknologier

Säkerhet

Att exponera intern data för Internet kan vara farligt, och säkerhetsindustrin är ständigt aktiv när det kommer till att identifiera och åtgärda sårbarheter i programvara och pro-tokoll. Django uppdateras ständigt i takt med att sårbarheter upptäcks, men utöver brister i mjukvara som kan exponera känslig data behöver också utvecklaren vara medveten om de risker som finns. Sårbarheter uppstår inte nödvändigtvis för att programvara innehåller sårbarheter, utan också för att utvecklare inte använder rätt metoder för att skydda sitt pro-gram. Django erbjuder inbyggda säkerhetsmetoder för att hjälpa utvecklaren skydda sig mot den vanligaste typen av attacker. Till exempel så erbjuder redan Django Models inbyggd funktionalitet för att filtrera den data som klienten bifogat i sin förfrågan innan informa-tionen slutligen sparas i databasen. Detta erbjuder ett säkert sätt att hantera data eftersom exekvering av ofiltrerade databasfrågor banar väg för sårbarheter som SQL-injektioner [18]. Att använda Djangos förinstallerade funktionalitet är således ett förhållandevis säkert sätt att utveckla sin server på, men man bör dessutom undersöka Djangos rekommendationer och utvärderingsverktyg innan okända klienter tillåts kommunicera med servern.

(13)

3

Teori

Teorikapitlet presenterar konceptet datarepresentation och de två format som har valts att studera för detta arbete.

3.1

Datarepresentation

Fielding beskriver tre tillvägagångssätt för hur informationen ska representeras i enlighet med REST [7]. Ett utav av tillvägagångssätten är att returnera rådata tillsammans med meta-data som beskriver informationen som skickats. De vanligaste metoderna för att presentera rådata är XML, JSON, HTML och ATOM [21]. Det här arbetet har begränsats till XML och JSON och avser undersöka vilket av de två som presterar bäst i det färdiga intranätet som utvecklats för arbetet.

Extensible Markup Language (XML)

XML är ett format för att representera data som 1998 introducerades som en standard av W3C [10]. XML använder element och attribut för att representera information som en träd-struktur [10]. Nedan följer ett exempel på hur ett meddelande skulle kunna se ut om det representerades som ett XML-träd.

<?xml version="1.0" encoding="UTF-8"?>

<message msg_id="10"> <header>

<subject>Message subject</subject>

<sender user_id="1">sender@email.com</sender>

<receiver user_id="2">receiver@email.com</receiver> <date>8 Feb 2017</date>

</header> <body>

This is a message!

</body> </message>

(14)

3.1. Datarepresentation

JavaScript Object Notation (JSON)

JSON är ett vanligt format som används för att representera data [10]. JSON beskriver data som en samling eller ett objekt. En array (samling) börjar med “[“ och avslutas med “]”, och de värden i samlingen separeras med ett kommatecken. Ett JSON-objekt är är en samling av par innehållandes ett namn och ett värde och börjar med “{“ och avslutas med “}”. Varje namn följs av ett kolon och värdet, och varje par av namn och värden separeras med kommatecken.

Figure 3.1: Samling (array) och objekt (object) i JSON. Källa: www.json.org

Nedan följer ett exempel på hur ett meddelande skulle kunna presenteras i JSON: {

"message_id": 10,

"subject": "Message subject",

"sender": "sender@email.com",

"receiver": "receiver@email.com",

"date": "8 Feb 2017",

"content": "This is a message!"

}

Tidigare studier

Rapportens frågeställning handlar om att besvara huruvida representationen av den över-förda datan bör vara i JSON- eller XML-format. Eftersom syftet med arbetet som ska genomföras är att underlätta ett företags underhållning och utveckling av hemsidor, i det här fallet ett intranät, har JSON från början ett försprång eftersom formatet stöds av JavaScript i grunden [19]. JavaScript kan, exempelvis, bearbeta JSON till och från JavaScript-objekt och vice versa utan att datan behöver tolkas av externa bibliotek. Eftersom 94 % av alla hemsidor använder JavaScript [20] och SysPartners intranät inte är ett undantag så är därför JSON i grunden ett mycket bra val av metod.

Vidare visar en publikation från 2009 att JSON presterar bättre än XML med avseende på hur snabbt bearbetningen av datan färdigställs [12]. Denna slutsats fattades utifrån resultaten av en serie tester där man jämförde JSON och XML. Det visar sig att JSON presterar bättre än XML i båda fallen. Denna slutsats styrks även av J. Einarsson och J. Winger-Lang som menar att JSON är det snabbaste valet oavsett objektens storlek, där avkodning av JSON-objekt sker upp till en faktor av 100 gånger snabbare än XML-motsvarigheten [6]. De menar också att JSON är det överlägsna valet när programmeringsspråket är Python eller JavaScript, där Python bearbetar JSON-objekt mellan 2,8 till 5,8 gånger snabbare än XML-motsvarigheten [6]. Det ligger också till fördel för JSON eftersom de ramverk som kommer att användas är utvecklade i Python.

(15)

4

Metod

I det här kapitlet presenteras metoderna som används för att genomföra arbetet och besvara rapportens frågeställning.

4.1

Analys

Syftet med API:et är att i slutändan erbjuda tillgång till samtlig data som utgör SysPartners aktuella intranät. Genom att studera den kod som utgör SysPartners intranät, databas och diskussion med relevanta anställda så fastställs en generell bild av den funktionalitet som API:et förväntas erbjuda. En specifikation framställs där de resurser som API:et förväntades kunna tillhandahålla specificeras, vilken URI som identifierar dem, samt vilka operationer klienten tillåts applicera på sina förfrågningar. Kravspecifikationen specificerar även hur olika typer av anställda ska hanteras där högre uppsatta behöver tillgång till mer informa-tion än övriga.

SysPartners aktuella intranät drivs inte isolerat av Drupal, utan är beroende av SysPartners active directory (AD) för användarhantering, rättighetshantering och filtrering av information. Således behövs en metod för att kommunicera med SysPartners AD via Django. SysPartner använder även VISMA för tidsrapporteringar och intranätet erbjuder funktionalitet för att se sin och sina anställdas tidsrapporteringar direkt via intranätet. Informationen hämtar intranätet från en lokalt underhållen Microsoft SQL-databas (MSSQL) som synkroniseras med VISMA:s databas regelbundet. Således krävs också ett sätt för Django att kommunicera med en MSSQL-server för att kunna bearbeta och visa tidsrapporteringar via API:et. Sys-Partners hårdvarubudget, som är en bonus anställda får att köpa utrustning för, kräver också integration med SysPartners AD för att anställdas hårdvarubudgetar ska kunna identifieras.

Användarhantering

Active Directory

SysPartners AD kommer att användas för två ändamål: autentisering och databearbetning. Autentisering mot AD är således klientens enda möjliga metod att autentisera sig för att låsa upp de olika nivåerna av data som API:et tillhandahåller. Vidare krävs ytterligare

(16)

funktion-4.1. Analys

alitet som möjliggör för API:et att avläsa information från SysPartners AD om användare, an-vändargrupper, information om användare, m.m. För ändamålen kommer django-auth-ldap [3] och django-ldapdb [5] att användas.

Tidsmodulen

Den typ av data som SysPartner vill erbjuda i intranätet finns inte hos VISMA, utan måste framställas av API:et. Denna data visar bland annat hur många timmar de anställda har rapporterat in som är fakturerbara av SysPartner, och hur mycket respektive lite de behöver arbeta under resterande månad för att ligga på 100 % arbetstid. Med hjälp av AD:t behöver klientens eventuella underanställda identifieras och returneras i API:ets svar. Detta för att ge chefer och gruppchefer en överblick över inte bara sin egen, utan även sina anställdas prestationer.

Microsoft SQL

SysPartners lokala MSSQL-server kommer att användas för att hämta tidsdata som de anställda har registrerat via VISMA. Det krävs därför funktionalitet som möjliggör för Django att interagera med en MSSQL-server på ett smidigt och pålitligt sätt. När väl funktionalitet finns som kan hämta information från databasen kommer Django att utföra själva bearbetnin-gen av datan. För kommunikationen mellan Django och MSSQL-servern kommer verktyget pyodbc [15] att användas. Pyodbc kräver i sin tur att det finns mjukvara och drivrutiner på servern som konfigurerats för SysPartners MSSQL-server.

Hårdvarubudget

Hårdvarubudgeten är en bonus som SysPartner delar ut till sina anställda varje månad och år där de anställda får extra pengar att köpa hårdvara för. Summan som tilldelas är beroende av flera olika faktorer, däribland den anställdes inrapporterade timmar för aktuell månad. En gång i månaden ska ett skript köras som itererar samtliga anställdas hårdvarubudget och utifrån dessa faktorer tilldelar en bonus. Precis som i tidsmodulen kommer AD:t att användas för att identifiera vilka anställda som den förfrågande klienten behöver ha tillgång till. Vidare krävs funktionalitet som tillåter högsta chefer att modifiera hårdvarubudgeten för att kunna bokföra budgetens kassaflöde och introducera nyanställda. Endast klienter som AD:t rapporterar som chefer kommer tillåtas att applicera metoder som DELETE, PUT och POST på API:ets resurser.

Databas

Som databasmotor kommer MySQL att användas [11]. Databasschemat är uppdelat i tre: hårdvarubas, bonus och historik. För varje ändring i en anställds budget måste ändringen sparas i historiken, och för varje månad när en bonus tilldelas måste den sparas i bonusta-bellen. Varje år genomförs en uträkning som adderar samtliga bonusar en anställd tilldelats under året med en viss summa (årlig bonus) och som sedan ska sparas i hårdvarubasen som lägger grunden för nästa års budgetunderlag.

Utvecklingsmiljö

För att understödja projektets struktur kommer Git att användas för att bokföra arbetets utveckling och möjliggöra för smidig versionshantering av koden. Vidare kommer ären-dehanteringssystemet Jira att användas för att planera arbetets fortskridande och ge en överblick över implementerad och icke-implementerad funktionalitet.

(17)

4.2. Design

4.2

Design

Utifrån de krav som API:et förväntas erbjuda och hur de olika modulerna representerades i Drupals databas framställs en övergripande plan över hur API:et ska utformas. Här specifi-ceras hur modulerna samarbetar, hur informationen ska representeras i databasen, hur API:et ska använda sig av SysPartners AD för användarhantering, hur tidsmodulen ska imple-menteras för att kommunicera med SysPartners MSSQL-server samt hur hårdvarubudgeten ska utformas.

Databas

Det aktuella intranätet är som tidigare nämnt utvecklat i Drupal och använder MySQL som databasmotor. Efter diskussion med företaget bestämdes det att MySQL skulle användas för att lagra information åt API:et eftersom det var en bekant och populär motor som inte lämnade några anledningar att byta. Databasschemat implementeras i en ny MySQL-databas och ett skript utvecklas med syftet att enkelt kunna återställa databasen till ett visst tillstånd. Datan som skriptet ska återställa till hämtas från en aktuell databaskopia för att kunna jämföra databasen med Drupals databas efter ändringar och beräkningar. Skriptet utvecklas med syfte att underlätta testandet av API:ets funktionalitet utan att manuellt behöva backa databasen under arbetets gång.

Eftersom hårdvarubudgeten är den enda information som kommer lagras i databasen är schemat mycket enkelt. Nedan visas det schema som kommer att resultera i databasta-beller. Djangos egna tabeller som används för bland annat sessionshantering och cache har utlämnats.

Figure 4.1: Databasdiagram över hårdvarubudgeten.

API

API:et kommer att delas upp i tre moduler: time_handler (tidshantering), budget_handler (bud-gethantering) och ldap_handler (användarhantering). Samtliga moduler kommer kommer att separeras ifrån varandra med syftet att göra dem modulära. Varje modul har i sin tur sina egna hjälpfunktioner, view-funktioner, models, m.m. Gemensamt för alla moduler är att de är beroende av användarhantering, och därför kommer samtliga att nyttja ldap_handler för att identifiera klienten och dennes eventuella underanställda.

(18)

4.3. Representationsmetod

vilka metoder som klienten kan applicera och vad API:et förväntas svara. Tillåtna metoder och filtrering av API:ets svar bearbetas utifrån klientens identiferade företagsposition.

Användarmodulen

Resurs URI Metoder Beskrivning

Användare /users/ GET Listar aktiva användare

från AD.

Användare /users/ăuidą GET

Returnerar enskild an-vändare identifierad av uid.

Tidsmodulen

Tidsdata /time/ GET Listar all beräknad

tids-data. Tidsdata /time/ăstartą/ăendą/ GET

Listar all beräknad tids-data inom angivet datu-mintervall.

Budgetmodulen

Budgetbas /budgetbase/ GET, POST Listar samtliga anställdas budgetbaser.

Budgetbas /budgetbase/ăuidą/ GET, PUT, DELETE

Listar enskild anställds budgetbas.

Budgetbonus /budgetbonus/ GET, POST Listar samtliga budget-bonusar.

Budgetbonus /budgetbonus/ăuidą/ GET, PUT, DELETE

Listar enskild användares budgetbonusar.

Budgethistorik /budgethistory/ GET, POST Listar samtlig budgethis-torik.

Budgethistorik /budgethistory/ăuidą GET, PUT, DELETE

Listar enskild användares budgethistorik.

Figure 4.2: Tabell över API:ets resurser.

4.3

Representationsmetod

Kvantitativ studie

För att komplettera litteraturstudien i teorikapitlet kommer en kvantitativ studie genomföras som utöver klienttester även studerar hur servern (API:et) påverkas av de två represen-tationsmetoderna. En mycket enkel hemsida kommer utvecklas som från API:et hämtar data som sedan bearbetas. Stresstestet aktiverar en klocka, skickar 300 förfrågningar till API:et, och mottar sedan successivt API:ets svar som bearbetas till JSON-objekt eller XML-objekt beroende på vilket test som körs. När testet har bearbetat samtliga svar från servern stannar klockan. För ändamålet kommer JavaScript-funktionerna JSON.parse och DOM-Parser().parseFromString() användas för att avkoda svaren till JSON respektive XML.

Parallellt med testerna som körs på klientsidan så ska även, på serversidan, minnesåtgång, CPU-användning och tiden det tar från att servern mottar klientens förfrågan till att ett svar returneras, att loggas. Till detta används verktyget psutil [14] där funktionen virtual_memory() används för att avläsa minnesåtgång och cpu_percent() används för att ge en decimalsiffra som representerar systemets CPU-användning. Av dessa kommer medelvärdena beräknas och ställas i relation till vilken representationsmetod som användes och hur lång tid det tog för klienttesterna att färdigställas.

(19)

4.3. Representationsmetod

data och det andra scenariot går ut på att bearbeta stora mängder data. Datan som API:et returnerar är faktiskt data som används av intranätet, med den enda skillnaden att för de stora mängderna data kommer samma data duplicerats 255 gånger.

(20)

5

Implementation

Nedan beskrivs hur arbetet, med metoden som utgångspunkt, implementerats.

API

Det första steget i utformningen av API:et var att implementera grundläggande funktion-alitet enligt kravspecifikationen. Denna grundläggande funktionfunktion-alitet består av in- och ut-loggning samt kallande på de funktioner som hämtar och modifierar API:ets resurser (hård-varubudget, tidsrapportering och användare). Under utvecklingen representerades all data som JSON, för att senare kompletteras med XML för att kunna besvara rapportens frågeställ-ning.

Användarhantering

För autentiseringen mot SysPartners AD användes modulen django-auth-ldap. Django kon-figurerades till att använda modulen för autentisering vilket möjliggjorde för att använda Djangos inbyggda autentiseringsverktyg i resterande delar av API:et. Den enda skillnaden var att användarens inloggningsuppgifter slogs upp mot SysPartners AD istället för en serverspecifik databas. Utöver autentisering användes också django-ldapdb för att hämta information från SysPartners AD som inte hade med autentisering att göra. I det här fallet användes modulen endast för att hämta användare och information om varje användare. Django-ldapdb är en modul som samspelar med Django Models, vilket gör django-ldapdb till ett ORM för AD-servrar.

Ingen data sparas på SysPartners AD via API:et, och för att förhindra oavsiktligt sparande användes en användare med enbart läsrättigheter. Information om användarna användes enbart för att bedöma deras olika rättigheter och för att binda samman den data som API:et hanterar med en specifik användare. En modell framtogs som hämtade nödvändig infor-mation från AD:t och representerade det som en objektinstans istället för rå text. Data som representerades var bland annat användarens för- och efternamn, användarnamn, grup-pchef, kontaktuppgifter och unika ID (objectGUID).

(21)

Figure 5.1: Lista över användare från API:et.

Tidshantering

API:et erbjöd tidsinformation om samtliga användare som bygger på en serie beräkningar som sker på information hämtat från den lokala MSSQL-servern. Även här var aldrig avsik-ten att spara data på databasen eftersom tidsrapporteringen sker via VISMA, och intranätets syfte var istället att räkna på de anställdas rapporteringar och erbjuda en överblick på sin egen och sina anställdas situation. Eftersom tidsrapporteringarna är många och MSSQL-databasen stor så utformades API:et till att utföra beräkningarna på en lokalt sparad cache som uppdateras var 15:e minut. Detta gav en drastisk ökning i effektivitet eftersom det sker ett stort antal uppslagningar särskilt för högre uppsatta anställda som behöver kunna se samtliga anställdas rapporteringar. För att kommunicera med SysPartners MSSQL-server används pyodbc som konfigurerades till att ansluta sig mot SysPartners MSSQL-server. Py-odbc är en modul som agerar brygga mellan en MSSQL-server och Django, vilket även här möjliggör för API:et att betrakta databasens innehåll som Django Models och den funktion-alitet som Django Models erbjuder.

När en klient anropade API:ets tidsmodul följde en serie beräkningar på tidsdata kopplade till klienten och dennes anställda. De slutgiltiga räknevärdena presenteras för användaren med syftet att antingen läsas direkt eller via ett grafiskt gränssnitt som tolkar värdena och pre-senterar dem för klienten på ett mer intuitivt sätt. Eftersom tidsmodulens logik är beroende av korrekt implementerad datumfunktionalitet användes ett öppet API för att hämta dagar

(22)

för varje månad och information om respektive dag (röd dag, arbetsdag, veckodag, m.m). Information därifrån användes för att beräkna de faktorer som slutligen resulterade i de räknevärden som API:et presenterar för klienten.

Nedan visas en bild på API:ets svar när tidsresursen begärs.

Figure 5.2: Ett utdrag ur API:ets tidsberäkning.

Budgethantering

Budgetmodulen utvecklades med stort fokus på vilken data klienten har tillgång till och att alla ändringar genomförs korrekt. För att göra detta så genomfördes alla nödvändiga beräkningar och kontroller före någon data sparades permanent i databasen. Detta innebar att samtliga ändringar i databasen genomfördes och kontrollerades, för att sedan skrivas till databasen i ett enda steg. På så sätt undviker API:et problem där en ändring har sparats i exempelvis budgetbasen medan inlägget i budgethistoriken inte kunde sparas. Innan infor-mationen slutligen sparades i databasen genomförs också en sundhetskontroll (sanity-check) på datan som bekräftar att det som Django tänker skriva till databasen stämmer överens med det förväntade resultatet. Dessa säkerhetsmetoder implementerades med syftet att säkerställa budgetens legitimitet. Eftersom budgeten hanterar anställdas rätt till pengar är det av stor vikt att all data som tas emot och returneras är korrekt, filtrerad och säker. Nedan visas en bild på API:ets svar när budgetbasen begärs.

(23)

Figure 5.3: Ett utdrag ur API:ets hårdvarubudget.

Testning

För att säkerställa API:ets funktionalitet utvecklades tester i takt med att API:ets funktion-alitet utökades. För ändamålet användes Djangos testramverk som tillät tester att exekvera på en temporär databas som skapas, fylls och förstörs varje gång testerna skapas. Testerna verifierar att användare kan logga in och komma åt de resurser de tillåts göra, och att de förhindras tillgång till övriga resurser. Testerna verifierar också att hårdvarubudgeten, som är den enda funktionalitet där data modifieras, uppdateras korrekt och att de ändringar som gjorts stämmer överens med förväntat slutresultat.

Säkerhet

Före de sista stegen som handlar om att öppna intranätet för omvärlden behövdes en del säkerhet beaktas. Djangos inbyggda hjälpfunktion check deploy1användes för att understödja

(24)

5.1. Front-end

sökandet efter eventuella säkerhetsbrister i API:et. Django konfigurerades till att inaktivera debugging, för att inte obehöriga skulle få ta del av felmeddelanden; inaktivera överförin-gen av Cross-Site Request Forgery (CSRF)-kakor och sessionskakor över okrypterad HTTP, omdirigering till HTTPS för alla anslutningar, aktivering av Djangos inbyggda skydd mot Cross site scripting (XSS)-attacker och ett förbud aktiverades som förhindrar alla klienter från att hämta data som visas i en HTML frame-tagg. Vidare konfigurerades en Apache webserver på en av SysPartners servrar till att servera Django-projektet bakom en krypterad HTTPS-anslutning och även här omdirigera osäker trafik till HTTPS-motsvarigheten.

5.1

Front-end

Tillsammans med SysPartner bestämdes det att arbetet i mån av tid även skulle innefatta utvecklingen av ett front-end till intranätet för att i praktiken använda API:et och kunna motivera eventuella förändringar. Eftersom front-end hamnar utanför ramarna för vad rapporten avser undersöka lämnas detta avsnitt kortfattat. Hemsidan utvecklades i ReactJS tillsammans med Bootstrap och körs parallellt i samma Django-instans som API:et. Varje modul i API:et representeras av en egen ReactJS-modul i intranätet som hämtar data från API:et och presenterar det för användaren. Trots att intranätet och API:et körs på samma server under samma Django-instans så hålls de alltså isolerade från varandra för att möjlig-göra för intranätet att kunna underhållas och köras separat från API:et. Alla datafiltreringar och säkerhetsbedömningar sköts av API:et för att inte exponera känslig data ty intranätets kod blir publik i samband med att den hämtas på klientens maskin.

Nedan visas en bild på gränssnittets tidsmodul.

Figure 5.4: Intranätets vy av tidsrapportering.

5.2

Representationsmetod

De mycket enkla klienttesterna utvecklades och API:et konfigurerades till att stödja både JSON och XML. Ett flertal tester exekverades för att verifiera att API och klient fungerar som förväntat innan de riktiga testerna kördes. För att mata klienten med data valdes API:ets lista över användare som datamängd, där datan duplicerats 255 gånger för det första scenariot.

(25)

5.2. Representationsmetod

Nedan visar två tabeller storleken på de datamängder som användes för testerna, och vilken testmiljö som användes. Som kan skådas är skillnaderna i filstorlek mellan JSON- och XML-formaterad data mycket liten och för arbetets syfte oväsentlig.

Scenario 1 (stor datamängd)

Format Filstorlek (bytes) Filstorlek (MiB)

JSON 13 149 843 12.541

XML 13 035 105 12.431

Scenario 2 (liten datamängd)

Format Filstorlek (bytes) Filstorlek (MiB)

JSON 51 572 0.0491

XML 51 134 0.0488

Figure 5.5: Tabell över filstorlekarna som används av testerna.

Testmiljö

Operativsystem Fedora 25 (64-bit)

Webbläsare Google Chrome v58 (64-bit) Processor Intel Core i7 4700HQ 2,4 GHz

Minne 12 GB DDR3 1600 MHz

(26)

6

Resultat

Nedan följer de testdata som givits av de tester som presenterats i metodkapitlet. Eftersom klienten behöver vänta på att API:et ska returnera ett svar så ger resultatet även en generell bild över hur API:et presterar. Denna generella bild kompletteras dock med resultaten från servern (API:et).

6.1

Scenario 1 - Stora datamängder

Tester där 300 st API-förfrågningar har begärts och besvarats för stora mängder data. Klient

Typ Total tid (sek) Total tid (min)

JSON 476.2 7.9

XML 1 081.5 18.0

(27)

6.2. Scenario 2 - Små datamängder Scenario 1 200 400 600 800 1,000 1,200 T id (sek) JSON XML

Figure 6.2: Stapeldiagram över klienttesternas resultat för scenario 1.

Server (API)

JSON XML

Medeltid per förfrågan (sek) 5.44 5.96

CPU medelvärde 14.2 16.2 CPU maxvärde 44.8 39 CPU minimivärde 4.3 3.9 Minnesanvändning medelvärde (%) 59.3 68 Minnesanvändning maxvärde (%) 63.8 74.8 Minnesanvändning minimivärde (%) 54.9 58.4

Figure 6.3: Resultat av serverns (API:ets) bearbetning av förfrågningarna för scenario 1.

6.2

Scenario 2 - Små datamängder

Tester där 300 st API-förfrågningar har begärts och besvarats för små mängder data. Klient

Typ Total tid (sek) Total tid (min)

JSON 25.7 0.43

XML 27.6 0.46

(28)

6.2. Scenario 2 - Små datamängder Scenario 2 0 10 20 30 T id (sek) JSON XML

Figure 6.5: Stapeldiagram över klienttesternas resultat för scenario 2.

Server (API)

JSON XML

Medeltid per förfrågan (sek) 0.14 0.16

CPU medelvärde 13.8 13 CPU maxvärde 46.2 29 CPU minimivärde 3.2 0.8 Minnesanvändning medelvärde (%) 60.1 59.5 Minnesanvändning maxvärde (%) 61 59.9 Minnesanvändning minimivärde (%) 59.1 59.2

(29)

7

Diskussion

7.1

Resultat

Resultaten visar hur API:et och klienten presterar när det kommer till att bearbeta data rep-resenterat i JSON och XML för två olika datamängder. De givna resultaten banar slutligen väg för att besvara arbetets frågeställning: "Vilken av representationsmetoderna JSON och XML ger bäst prestanda för ett API och en klient med avseende på bearbetningstid och resursförbrukning?".

Klient

Scenario 1 - Stora datamängder

Testresultaten visar att klienten bearbetar stora JSON-datamängder 128 % mer effektivt än för stora XML-datamängder där den totala tiden var 7.9 minuter respektive 18 minuter. Scenario 2 - Små datamängder

För klientens bearbetning av små datamängder visar sig resultaten vara förhållandevis likvärdiga. Bearbetningen av den mottagna JSON-datan sker 7 % mer effektivt än XML-motsvarigheten. Mätt i sekunder är skillnaden bara 1.9 sekunder där JSON-datan bearbe-tas på 25.7 sekunder och XML-datan bearbebearbe-tas på 27.6 sekunder. För små datamängder är således tidsskillnaden försumbar för icke-tidskritiska applikationer även om JSON:s snab-bare bearbetningstid inte är att förglömma.

Slutsats - Klient

Resultaten menar att klientens JavaScript bearbetar stor och liten JSON-data mer effektivt än XML-motsvarigheten, med en tidsbesparing på 128 % respektive 7 %. Således kan ena delen av frågeställningen besvaras genom konstaterandet att JSON ger bäst prestanda med avseende på bearbetningstid för JavaScript-klienter. Detta förefaller rimligt när man beaktar att JavaScript erbjuder inbyggd funktionalitet för att bearbeta JSON med JSON.parse(), som nämnt i metodkapitlet. XML å andra sidan kräver att datan tas emot för att sedan helt itereras genom och till sist få sin data extraherad och lagrad i variabler, vilket är en mer krävande uppgift.

(30)

7.1. Resultat

Server (API)

Scenario 1 - Stora datamängder

API:ets testresultat visar att bearbetningen av JSON respektive XML-data är förhållandevis likvärdiga, även om XML-bearbetningen förbrukade en större andel systemresurser. Medelti-den det tog för varje mottagen förfrågan att förberedas och slutligen returneras var 5.44 sekunder för JSON-testet och 5.96 sekunder för XML-testet där JSON-förfrågningarna alltså bearbetates 9.6 % snabbare. Den decimalsiffra som representerar CPU-användningen lan-dade på ett medelvärde på 14.2 för JSON-testet och 16.2 för XML-testet. Samma trend visas i medelanvändningen av systemets minne där systemet under JSON-testet förbrukade 59.3 % av systemets virtuella minne medan XML-testet förbrukade 68 %. En mer drastisk skillnad i medeltid per förfrågan förväntades i och med att metodens litteraturstudie tydde på större överlägsenhet för Pythons bearbetning av JSON-data. Det skall dock beaktas att den slutsat-sen fattades av stresstestandet av ett litet Pythonprogram som endast bearbetade JSON- och XML-data, medan API:et använt för denna rapport istället bestod av ett helt ramverk. Förfat-tarna själva skriver att "De simpla program vi skrivit i JavaScript och Python är gjorda så att de ska utföra så lite onödigt arbete som möjligt." [6], och medan API:et inte heller avser utföra onödiga uppgifter så är det ett mer komplext system där mycket funktionalitet är involverat i bearbet-ningen av den data som slutligen returneras. En annan bidragande faktor är att Pythonpro-grammet i ovan nämnd studie bearbetar rådata till- och från JSON respektive XML, medan API:et enbart renderar samma data till JSON eller XML.

Scenario 2 - Små datamängder

Även för små datamängder visade sig API:et ha en lägre medeltid per förfrågan där JSON-testet gav en medeltid på 0.14 sekunder medan XML-JSON-testet istället hamnade på 0.16 sekun-der; en skillnad på 14 %. Mätt i sekunder är dock skillnaden mycket liten, och för API:ets syfte försumbar. När istället förbrukade systemresurser studeras så visas en mindre fördel för XML-testet. CPU-användningen för JSON-testet resulterade i ett medelvärde på 13.8 re-spektive 13 för XML-testet. CPU-användningen hade också ett betydligt högre maxvärde för JSON-testet jämfört med XML-testet, där värdet resulterade i 46.2 respektive 29. Skillnaden i de två testernas maxvärde låg till JSON:s nackdel även för stora datamängder i scenario 1, om än inte lika drastisk. Vidare visar det sig att systemet under JSON-testet förbrukade 1.5 procentenhet mer virtuellt minne än XML-motsvarigheten.

Slutsats - API

Testresultaten visar att API:et presterar bäst i JSON-testen för både stora och små datamängder med avseende på bearbetningstid. Vad gäller förbrukade systemresurser var dock resultaten varierande där stora datamängder resulterade i att XML-förfrågningarna brukade mer resurser när man beräknade dess medelvärden. För små datamängder för-brukade istället JSON-förfrågningarna mest systemresurser, även om skillnaderna är små. Med resultaten som utgångspunkt besvaras frågeställningen där JSON för både små och stora datamängder gav bäst bearbetningstid per förfrågan. Vad gäller resursförbrukning presterade JSON-testet för stora datamängder bättre än XML, medan XML-testet presterande marginellt bättre än JSON för små datamängder.

Slutsats

Testresultaten visar att datamängder i JSON-format gav bäst resultat i både bearbetningstid och systemförbrukning för både stora och små datamängder, bortsett från det fall där XML hade marginellt lägre medelresursförbrukning för små datamängder. Det skall dock inte förglömmas att i det fall då XML-formatet gav minst resursförbrukning var medeltiden per förfrågan fortfarande lägre för JSON-formatet, och skillnaden i resursförbrukning var endast

(31)

7.2. Method

marginell. Utifrån testresultaten och den diskussion som förts i samband med dessa kon-stateras det slutligen att svaret på arbetets frågeställning, Vilken av representationsmetoderna JSON och XML ger bäst prestanda för ett API och en klient med avseende på bearbetningstid och resursförbrukning?, är JSON.

Det bör dock inte förglömmas att testresultaterna inte berättar om dataformatens påverkan på systemet efter att klienten har tagit emot och koverterat datan till interna objekt. Det kan alltså finnas faktorer som påverkar de båda dataformatens effektivitet när datan ska användas för framställning av ny data eller datan ska valideras. Till exempel så erbjuder XML-formatet ett verktyg, XML Schema, som kan användas för att validera datans struktur. Detta arbete har istället fokuserats på de båda dataformatens påverkan på klient och system från att datan framställs tills att den tagits emot och är redo att behandlas ytterligare hos klienten.

7.2

Method

API

Arbetet med att utveckla det API som skulle lägga grund för den kommande kvantitativa studien hindrades flera gånger av ett behov att refaktorera små och stora delar av kodbasen. Eftersom erfarenheten av såväl ramverket Django som språket Python båda var tämligen små upplevdes det i samband med att programmet växte ett större behov av att göra om, göra rätt. Det är svårt att göra om arbetet utifrån samma situation som innan och förvänta sig ett annorlunda resultat, men om uppgiften istället skulle tilldelas mig idag när erfarenheten finns hade jag från början lagt ner mer tid på att planera hur kod skulle struktureras och hur moduler skulle samarbeta. Alternativet är att, som gjorts nu, skriva kod som refaktoreras när bättre lösningar identifieras, men det är knappast en effektiv lösning. Å andra sidan så är jag väldigt nöjd med slutresultatet, och det som hade kunnat erhållits av bättre planering är effektivitet snarare än annorlunda kodbas.

I efterhand identifieras dock två områden som hade förbättrat både aktuell kodbas och arbetets effektivitet. Det första handlar om sessionshantering, där Django erbjuder mycket kompetent funktionalitet för att hålla reda på vilken klient det är som anropar API:et. När en klient anropar API:et så finns bland annat användarens användarnamn lagrat i det bi-fogade sessionsobjektet som view-funktionerna tar emot. En bättre lösning hade varit att från början överlagra autentiseringsmodulen som sparar denna data i sessionsobjektet vid autentisering mot SysPartners AD, och istället lagra användarens ID (ObjectGUID). Detta på grund av att ID:t används för att identifiera användare i hela API:et, från att begära speci-fika resurser från API:et till att internt identifiera användarens tillhörande hårdvarubudget, VISMA-användare, m.m. Som det ser ut nu så sker en hel del uppslagningar mot AD:t där ett användarobjekt får hämtas identifierat av det användarnamn som erhålls av det förfrågande sessionsobjektet. Detta sker såväl som i varje view-funktion som i flera av hjälpfunktionerna. Att därför direkt ha möjlighet att hämta en användare från AD:t utan att först behöva hitta dennes ID hade därför underlättat en hel del vad gäller både kodstruktur och effektivitet. En ännu bättre lösning hade varit att direkt vid autentisering hämta relevant användarob-jekt från AD:t som sedan refereras till i sessionsobanvändarob-jektet. Det gör förvisso systemet mindre skalbart, men i dagens användningsområde för API:et är det bekymret irrelevant.

Det andra bekymret handlar om VISMA:s databas och de många hämtningar av dess data. SysPartner har en lokal kopia på databasen som man använder internt för bland annat det äldre intranätet och det som utvecklats under detta arbete. Den här databasen är dock väldigt långsam, vilket resulterade i att för anställda som i tidsmodulen har tillgång till flera

(32)

anställ-7.3. Studie

tidsrapporter blev databasförfrågningarna många och väntetiden var mellan 30 sekunder och en minut. För att lösa det problemet valde jag att spara en hel del data som cache. Det gjorde API:et mycket snabbare, men det är fortfarande obekvämt att tvingas underhålla funktionalitet som vid ett visst tidsintervall sparar all denna data i en lokal databas. Efter att den lösningen implementerats fick också en hel del kod skrivas om då uppslagningarna nu skulle göras mot den sparade kopian, som bara var stora textsträngar, snarare än mot VISMA:s databas. Det är heller inte en skalbar lösning eftersom datan som sparas vid en viss tidpunkt kan bli alldeles för stor. En bättre lösning hade varit att utveckla funktionalitet som hämtar all relevant data från VISMA:s databas som krävs för att bearbeta flera anställda på en gång utan att behöva hämta specifik data för varje användare som itereras igenom. Att bara behöva skicka en förfrågan hade alltså löst behovet av cache eftersom flaskhalsen i situationen var mellan API och VISMA:s databas.

REST

Arbetets utgångspunkt var att det utvecklade API:et skulle följa de principer som REST in-nebär. Det visar sig att det slutgiltiga API:et till mångt och mycket lever upp till de principer som Roy Fielding myntade i sin avhandling [7]. API:et är tillståndslöst och fattar inga beslut som påverkas av vilket tillstånd klienten befinner sig i, bortsett från vilken anställningsform som den inloggade klienten har. Varje tillgänglig resurs identifieras med en unik URI som klienten kan applicera olika HTTP-metoder på beroende på vad klienten vill åstadkomma. För att ytterligare filtrera data kan klienten bifoga parametrar i sin förfrågan, och använder klienten API:et fel svaras denne med en representativ felkod och ett felmeddelande innehål-landes orsak till att dennes begäran inte kunde bearbetas. För att göra API:et användbart men samtidigt intuitivt har också ett användargränssnitt utvecklats som är skilt från API:et. Användargränssnittets syfte är enbart att kommunicera med API:et, och utifrån API:ets svar hjälpa användaren navigera informationen.

7.3

Studie

Eftersom den data som användes i testerna bestod av intern, möjligtvis känslig, data från SysPartner finns den inte tillgänglig som bilaga. Detta innebär att studiens replikerbarhet blir lidande, även om studien istället har kompletterats med storleken på den data som testerna använde sig av. Eftersom API:et ej heller existerar som varken bilaga eller öppen källkod så är det i praktiken omöjligt att på ett helt korrekt sätt replikera den server som testerna anropar, även om API:ets moduler har beskrivits i metodkapitlet. Däremot så har de funktioner som testerna använder sig av för att bearbeta mottagen data och rapportera resursförbrukning klarlagts vilket innebär att samma tester kommer kunna utföras fast på annan data och med en annorlunda server.

Vad gäller serverns pålitlighet så kan även resultatet påverkas av en egenimplementerad server eftersom den funktionalitet som till slut returnerar data från servern, som nämnt, inte är tillgänglig. Det bör dock nämnas att det är samma funktionalitet som använts för både JSON- och XML-testerna bortsett från att renderingsmotorn är annorlunda för de två olika representationsmetoderna. Således bör man kunna dra slutsatsen att resultaten blir propor-tionerliga även för en egenimplementerad server. Detta på grund av att den funktionalitet som förbereder datan inte har något med JSON eller XML att göra.

Validitetshot

Biblioteken som används för att bearbeta data och ange resursförbrukning är väl beprövade och koden är öppen, och den data de rapporterar får för syftet därför bedömas som tro-värdiga. Däremot så har bara klienttesterna exekverats i Google Chrome. Enligt

(33)

hemsi-7.4. Källkritik

dan DigitalTrends hamnade Google Chrome v55, två versioner äldre en den som använts i testerna, på andraplats i den del som stresstestar JavaScript med verktyget Kraken JavaScript v1.1 efter webbläsaren Vivaldi [1]. Google Chrome är alltså ett fullgott alternativ när det kom-mer till att stresstesta JavaScript, även om ytterligare webbläsare i testerna hade stärkt dess validitet. Vidare är Djangos utvecklingsserver (vilken användes i testerna) konfigurerad att bearbeta sex förfrågningar i taget. Det betyder att av de 300 förfrågningar som klienttesterna skickade till servern så bearbetades bara sex av dem i taget. Om ändringar görs i konfig-urationen eller om en annan server med annan konfiguration används för att driva API:et kommer därför resultatet se annorlunda ut. Om exempelvis alla förfrågningar bearbetas sam-tidigt kommer det ta väldigt lång tid för den sista att färdigställas, och servern kommer också förbruka mer systemresurser eftersom den kommer att arbeta med ett annat antal uppgifter parallellt.

7.4

Källkritik

Några av de källor som hänvisats till i arbetet kommer från artiklar och bloggar. I de fall detta förekommer är det dock främst med syfte att motivera eller stärka en viss utgångspunkt, som exempelvis den blogg som presenterade ett diagram över REST-arkitekturens framfart [9]. Ansträngningar har dock gjorts för att i de fall hemsidor hänvisats till i rapporten hitta information som hemsidan i sin tur har angivit som källa, men dessa ansträngningar har inte alltid lyckats. I vissa fall är hemsidorna i referenslistan hänvisade till projekts egen dokumen-tation, som får bedömas som de mest trovärdiga källorna när det kommer till hur projektet ska användas och vad det erbjuder. I övrigt så har stora ansträngningar gjorts för att hitta relevant och aktuell information, och flera publikationer har förkastats på grund av sin ålder till förmån för en nyare informationskälla. Detta gäller även publikationer som aldrig eller bara några enstaka gånger citerats, om en mer trovärdig ersättare har kunnat finnas. För de publikationer med fler citeringar har å andra sidan citeringarna granskats för att skapa en uppfattning om i vilka sammanhang publikationen har blivit citerad i, och om orsaken till citat har varit i positiv eller negativ bemärkelse.

(34)

8

Slutsats

Syftet med rapporten var att undersöka vilka representationsmetoder som presterade bäst i ett API och en klient med avseende på den tid det tar att bearbeta datan och vilka sys-temresurser som går åt. För syftet valdes typerna JSON och XML. Eftersom syftet med arbetet också var att kunna fatta en slutsats som är anknuten till SysPartner och deras behov utvecklades ett komplett intranät att bedriva testerna på, snarare än ett simpelt API-skelett. Resultaten visar att JSON presterar bäst på både server- och klientsida för både stora och små datamängder, bortsett från att XML förbrukade marginellt mindre systemresurser på serversidan för små datamängder. JSON-motsvarigheten hade dock hade en lägre medeltid per förfrågan för samma scenario. Syftet med rapporten har således uppfyllts ty arbetets lär-domar har diskuterats och frågeställningen, vilken av representationsmetoderna JSON och XML ger bäst prestanda för ett API och en klient med avseende på bearbetningstid och resursförbrukning?, har besvarats: JSON-formaterad data resulterade alltid i snabbare bearbetningstid än XML-motsvarigheten. JSON-formaterad data förbrukar också mindre systemresurser, förutom när datamängderna är små då medelförbrukningen av systemresurserna var marginellt högre än XML-motsvarigheten.

Arbetets resultat har möjlighet att användas som underlag för framtida val av representa-tionsmetod av både företag, privatpersoner och forskare. Eftersom resultaten beskriver hur representationsmetoderna har påverkat såväl bearbetningstid som resursanvändning finns möjlighet att beakta och prioritera utifrån de konsekvenserna som representationsmetoderna innebär. Till exempel kan resultaten användas för att avgöra olika representationsmetoder för tidskritiska applikationer eller resurskritiska applikationer.

8.1

Framtida arbete

Intressant framtida arbete är att mer noggrant studera JSON och XML:s påverkan på sys-temet som helhet med fler mätvärden. Detta skulle kunna innebära att man i större utsträck-ning testar flera delar av API:et i ett isolerat system som inte påverkas av de externa faktorer som detta arbetets tester gjorts. Testerna i detta arbete har utförts på en personlig dator, och ansträngningar har gjorts för att de olika testerna ska kunna göras med samma förut-sättningar. Det är dock inte jämförbart med ett minimalt, kontrollerat och isolerat system som möjliggör för testerna att bättre mäta resursförbrukning och tidseffektivitet. Ett sådant

(35)

8.1. Framtida arbete

system skulle också bana väg för mer trovärdiga avläsningar av andra faktorer som nätverk-strafik, buffrar, köbildning i processorn, m.m. Det skulle också möjliggöra för att kunna sep-arera klient- och servertesterna eftersom de skulle kunna köras helt separat på olika fysiska eller virtuella maskiner.

(36)

Bibliography

[1] Battle of the browsers: Edge vs. Chrome vs. Firefox vs. Opera vs. Vivaldi. URL: https:// www.digitaltrends.com/computing/best-browser-internet-explorer-vs-chrome-vs-firefox-vs-safari-vs-edge/(visited on 05/15/2017). [2] Django.URL: https://www.djangoproject.com/ (visited on 03/01/2017). [3] Django Authentication Using LDAP.URL:

https://pythonhosted.org/django-auth-ldap/(visited on 05/15/2017).

[4] Django REST Framework. URL: http : / / www . django - rest - framework . org/ (visited on 03/01/2017).

[5] Django-ldapdb.URL: https : / / github . com / django - ldapdb / django - ldapdb (visited on 05/15/2017).

[6] Joel Einarsson and Johannes Winger-Lang. “En jämförande prestandastudie mellan JSON och XML”. B.S. Thesis. Blekinge Institute of Technology, Department of Software Engineering, 2014, p. 54.

[7] Roy Thomas Fielding. “Architectural styles and the design of network-based software architectures”. PhD thesis. University of California, Irvine, 2000.

[8] ICT Facts and Figures 2016.URL: https://www.itu.int/en/ITU-D/Statistics/ Documents/facts/ICTFactsFigures2016.pdf(visited on 03/01/2017).

[9] Guy Levin. The Rise of REST API.URL: http://blog.restcase.com/the-rise-of-rest-api/(visited on 03/01/2017).

[10] B. Lin, Y. Chen, X. Chen, and Y. Yu. “Comparison between JSON and XML in Applica-tions Based on AJAX”. In: 2012 International Conference on Computer Science and Service System. Aug. 2012, pp. 1174–1177.DOI: 10.1109/CSSS.2012.297.

[11] MySQL.URL: https://www.mysql.com/ (visited on 06/09/2017).

[12] Nurseitov Nurzhan, Paulson Michael, Reynolds All, and Izurieta Clemente. “Izurieta C: Comparison of JSON and XML Data Interchange Formats: A Case Study. Scenario 2009.” In: (2014).

[13] Cesare Pautasso. “RESTful Web Services: Principles, Patterns, Emerging Technologies”. In: Web Services Foundations. Ed. by Athman Bouguettaya, Quan Z. Sheng, and Florian Daniel. New York, NY: Springer New York, 2014, pp. 31–51.ISBN: 978-1-4614-7518-7. DOI: 10.1007/978-1-4614-7518-7_2.

(37)

Bibliography

[14] Psutil.URL: https://pythonhosted.org/psutil/ (visited on 05/15/2017). [15] Pyodbc. URL: https : / / github . com / mkleehammer / pyodbc (visited on

05/15/2017).

[16] Fielding R., Gettys J., Gettys Internet-draft J., Frystyk H., Berners-lee T., Mogul Mit/lcsj C., Dech J. Gettys, Mogul J. C., and Bernerslee T. “Hypertext Transfer Protocol -HTTP/1.1.” In: (2009).

[17] Guido Schmutz, Daniel Liebhart, and Peter Welkenbach. Service-oriented Architecture: An Integration Blueprint: a Real-world SOA Strategy for the Integration of Heterogeneous Enterprise Systems: Successfully Implement Your Own Enterprise Integration Architecture Using the Trivadis Integration Architecture Blueprint. Packt Publishing Ltd, 2010.

[18] Security in Django.URL: https://docs.djangoproject.com/en/1.11/topics/ security/(visited on 05/15/2017).

[19] W3schools - JSON.URL: https://www.w3schools.com/js/js_json_intro.asp (visited on 03/01/2017).

[20] W3techs. URL: https : / / w3techs . com / technologies / details / cp -javascript/all/all(visited on 03/01/2017).

[21] L. Xiao-Hong. “Research and Development of Web of Things System Based on Rest Architecture”. In: 2014 Fifth International Conference on Intelligent Systems Design and En-gineering Applications. June 2014, pp. 744–747.DOI: 10.1109/ISDEA.2014.169.

References

Related documents

För att kunna göra mätningar på prestanda, men även bedöma användarvänligheten av de två biblioteken Jansson och YAJL så har jag utvecklat ett testprogram.. Testprogrammet

Det finns lösningar på marknaden i olika former för detta redan men frågan är att se vilket databassystem av PostgreSQL och MongoDB som kan tänkas prestera bättre när det

Figur 5.2: Diagram som visar de stora skillnaderna på konverteringstid i test 5-8 på system 1 för JSON och XML med liten datamängd, samt skillnaden mellan olika webbläsare..

The JBI standard does not specify any standard mechanism or API for enabling people to get non-XML data into the ESB (or for converting non-XML data to XML). Like I said the Encoder

To implement such a system, three primitive foreign functions are defined to allow queries to JSON streams using the query language AmosQL of Amos II.. The usefulness of the

Vilket leder till att Kwalify inte kan användas för att validera JSON.. Parsern för Kwalify följer inte specifikationen för YAML fullt

While comparing the results from execution using different amount of threads with a profiling tool the thread-execution-visualization indicates that the amount of time spent on

Till skillnad från Microsofts Word, är XML en öppen standard och ägs inte av någon, det är fritt fram för alla som vill implementera stöd för XML i programvaror att göra