4.4 Relationwise
5.5.2 Uppdelning av webbapplikationer
Enkätmodulen består dels av en designdel och dels av en svarsdel. Dessa båda applikationer är fristående och kan köras på samma webbserver eller på två olika. Kommunikationen mellan dem sker via HyperText Transfer Protocol (HTTP) eller det säkrare så kallade HTTPS-protokollet.
5.5.3 Webbapplikationernas struktur
Det finns flera modeller för att strukturera webbapplikationer. När Sun utvecklade JSP definierade de två modeller6, Modell 1 och Modell 2, för
utveckling avJSP-baserade webbapplikationer.
Modell 1 är den enklare modellen som främst passar bra för mindre applikationer. Den innebär att logik- och presentationslagren inte är åt- skilda, utan att logiken finns i JSP-filer blandad med kod för presentatio-
nen i webbläsaren. Datalagringen är däremot fristående och använder sig avJavaBeans, så kallade bönor, för datatransport och viss lagring.
Modell 2 har samtliga lager åtskilda vilket gör att denna modell är mer flexibel och komplicerad, vilket i sin tur medför att den läm- par sig bättre för större projekt. Istället för att utföra logiska operatio- ner direkt på varje sida som visas, utförs detta i modellagret. Koordina-
2URL:http://jakarta.apache.org/tomcat/ 3URL:http://java.sun.com/products/servlet/ 4URL:http://java.sun.com/products/jsp/ 5URL:http://eclipse.org/webtools/index.html 6URL: http://java.sun.com/developer/onlineTraining/JSPIntro/ contents.html
tionen mellan visnings- och modellagret sköts av kontrollagret. Modell 2 är en webb- och Javaspecifik tillämpning av Model-View-Controller- arkitekturen, MVC, som i sin tur är en mjukvaruarkitektur. Vi översät-
ter Model-View-Controller med Modell-Visning-Kontroll, men använder
MVCför att förkorta begreppet.
Modellagret innehåller dels affärslogiken och dels ett gränssnitt till da- tat eller de tjänster som används av applikationen. Kontrollagret tar hand om de förfrågningar som skickats från klienten till applikationen och an- ropar lämpliga delar av modell- och visningslagren. Visningslagret gene- rerar användargränssnittet.
Figur 5.1 på sidan 32 visar hur det går till vid en sidvisning där sidan som ska visas genereras från en webbapplikation enligt Modell 2 [22].
En begäran (eng. request) skickas från användaren via webbläsaren.
Den tas emot av kontrollagret som i sin tur använder modellagret för att ta fram ett lämpligt svar. Vid behov hämtar modellagret data från data- lagret som till exempel kan vara en databas. Svaret publiceras till exempel med hjälp av enJSP som bland annat skickar en webbsida som svar (eng.
response) till användarens webbläsare.
Figur 5.1: Flödet för en sidvisning med Modell 2.
Vi särskiljde i möjligaste mån logiken, datahanteringen och användar- gränssnittet från varandra och valde alltså Modell 2. Även om våra appli- kationer blev förhållandevis små så var det bra att strukturera ordentligt,
5.5. Implementationsteori 33
för att lätt kunna bygga om eller ut, samt få en bra översikt.
Ramverk
Ramverket Struts7 är framför allt ett verktyg som håller ordning på och strukturerar kontrollagret och bönorna. Flödet i applikationerna beskrivs i en XML-fil. I denna fil beskrivs vilka delar av kontrollagret som ska an-
ropas beroende på angiven URL eller på tidigare resultat från affärshän-
delserna i logiklagret. I denna fil specificerar man även vilka bönor som används för att ta hand om data vid olika händelser.
Det finns många andra alternativ som stöder användandet av Modell 2, till exempel Barracuda8, Jakarta Tapestry9och Maverick10. Struts är gra- tis och har öppen källkod, licensierat under Apache Software License11. Struts har utvecklats och mognat under en längre tid, vilket gör att det är stabilt, välutvecklat och rikligt dokumenterat både i tryckt form och på webben. Ett annat tungt vägande argument för Struts är att Asynja har på- börjat en migration mot Struts och att Struts är ett populärt val för denna typ av lösningar. Vårt val föll därför på Struts.
5.5.4 Datalagring
En av de stora frågorna som vi skulle ta ställning till var hur data om till exempel frågesamlingarnas utformning och respondenternas svar skulle lagras. De två huvudalternativen var lagring i relationsdatabas eller i text- filer i exempelvisXML-format. All data behövde inte lagras på samma sätt,
men datalagringsformatet skulle vara väldokumenterat och det skulle gå att transportera datat enkelt mellan system. Vi ville att man skulle kunna skapa exempelvis frågesamlingar i andra system och sedan kunna expor- tera dem till enkätmodulen. Svarsdata från enkäterna borde kunna impor- teras från till exempel Asynja utan större svårighet.
Ytterligare ett alternativ som kan användas för att lagra interna data är att spara ner de bönor som används för intern lagring på hårddisk. Interna data är de data som inte importeras eller exporteras.
7URL:http://struts.apache.org/
8URL:http://barracudamvc.org/Barracuda/
9URL:http://jakarta.apache.org/tapestry/
10URL:http://mav.sourceforge.net/
Relationsdatabas
Vi ville inte ställa krav på att en relationsdatabas skulle finnas installerad på den eller de webbservrar som skulle köra applikationerna. Om vi hade använt denna datalagringsmetod borde vi antagligen ha en Java-baserad databas som vi skulle ha skickat med applikationerna. Ett exempel på en dylik relationsdatabas är HSQLDB12 som är snabb, gratis och stödjer det
ramverk som Asynja avsåg att använda, Hibernate13. Om vi skulle använ- da en relationsdatabas borde vi studera och eventuellt använda Hibernate för att översätta en objektorienterad domänmodell till en traditionell rela- tionsdatabas i Java.
Det fanns sedan tidigare möjlighet att skapa enkäter i HTML-format i
Asynja, utifrån information i en relationsdatabas. Om vi inte använde en liknande relationsdatabas skulle vi gå miste om redan skriven kod.
XML-filer
Fördelar med XML-filer är exempelvis ökad portabilitet och lättförståeli-
ga filer. Det blir lättare att definiera ett externt gränssnitt samtidigt som det finns många mogna verktyg för att hanteraXML-strukturer. Enkäterna
skulle presenteras som HTML-formulär och det finns bra och lättanvän-
da verktyg för denna omvandling i Java med hjälp avXSL Transformation
(XSLT), som är en del av Extensible Stylesheet Language (XSL). HTML, XML
och XSL är alla World Wide Web Consortium14-standarder (W3C). XML-
filer är även lätta att omvandla till andra format, exempelvisPDF.
En nackdel med XML som ska översättas till HTML är att det kan va-
ra omständligt om man behöver skriva många XSLT-filer, till exempel en XSLTtill varjeXML-fil om alla skiljer sig åt. Detta blir inget problem för oss
eftersom vi bara har en XML-fil som ska omvandlas till HTML, nämligen
enkätfilen.
Det kan dock vara svårt att skriva dennaXSLT-fil om till exempelXML-
filens uppbyggnad är krånglig alternativt dåligt anpassad för ändamålet. Vid användandet av en relationsdatabas med möjlighet att ställa frågor, till exempel SQL-frågor, kan det i vissa sammanhang vara enklare att få
ut alla kombinationer av datat i databasen. Denna nackdel kan avhjälpas med god design av deXML-filer som ska transformeras.
12URL:http://www.hsqldb.org/
13URL:http://www.hibernate.org/
5.5. Implementationsteori 35 Serialiserade bönor
En fördel med att serialisera de bönor som innehåller enkätundersökning- ar är att det låter sig göra smidigt. Bönorna kan då sparas ner i sin helhet utan att data behöver skyfflas runt och omförpackas. En nackdel är att koden för att serialisera bönorna blir specifik för det interna datat och där- med inte kan återanvändas för övrig datalagring.
Vårt val av datalagringsmetod
För oss var utbytet av data till och från andra applikationer viktigt, samti- digt som vi inte ville ställa krav på databashanterare eller skicka med för vårt projekt onödig mjukvara. De data som skulle lagras var förhållande- vis lätta att modellera och väl anpassade för XML-formatet. Det är enbart
uppgifter om enkätundersökningar samt inloggningsuppgifter för admi- nistratörer som behövde lagras utöver de data som importerades till eller exporterades från vårt system. Vi behövde således transformera en typ av
XML-fil med hjälp avXSLT vilket gjorde att detta inte upplevdes avskräc-
kande.
Eftersom det bara var enkätundersökningarna som är interna data och metoder för att spara övriga data ändå behövdes fanns det ingen större anledning att spara ner det interna datat på ett särskilt sätt. Detta gjorde att alternativet med serialiserade bönor föreföll mindre lämpligt.
Fördelarna med XML-formatet övervägde för våra applikationer och
därför valde vi detta till de data som skulle lagras beständigt, till exempel enkät-, målgrupps- och enkätundersökningsdata.
5.5.5 Inloggning
Autentisering kan ske på flera sätt. Det vanligaste sättet att autentisera är med hjälp av en kombination av ett användarnamn och ett lösenord. Dessa anges i textform för att visa för applikationen att man är den man utger sig för att vara.
Att autentisera med hjälp av användarnamn och lösenord låter sig gö- ras på ett flertal sätt när man använder sig av en webbapplikation som körs under Tomcat. Det går exempelvis att använda sig av Tomcats in- byggda autentiseringsmetoder men eftersom vi lagrade användaruppgif- ter i ett eget XML-format var det enklast att utforma autentiseringen på
egen hand. JAAS är ett Javabibliotek som kan användas som stöd för ut-
vecklingen av autentiseringsfunktionen. Denna verkade mer avancerad än vad våra applikationer krävde så vi valde att skriva egna metoder för
att matcha användarnamn och lösenord mot XML-filerna med användar-
uppgifter.
Våra applikationer autentiserar två typer av användare, dels administ- ratörerna som skapar, redigerar och publicerar enkätundersökningar men även respondenterna som loggar in för att svara på en enkät. De sistnämn- da använder sig av en kombination av användarnamn och lösenord som enbart är giltiga till dess att respondenten har svarat på enkäten.
Alla administratörer har samma behörighetsnivå och kan till exempel redigera varandras enkätundersökningar.
Kopplingen mellan respondenternas användarnamn och verkliga namn finns inte i våra applikationer utan endast i det system som har ska- pat målgruppsdatat. Respondenternas användarnamn och lösenord som används i våra applikationer bör vara slumpgenererade och inte gå att koppla ihop med personen.
5.5.6 Kryptering
Kryptering används för att skydda information och eftersom vi behandlar information som kan vara känslig var det viktigt att skydda dessa upp- gifter. Enkätsvaren kan innehålla uppgifter av medicinsk karaktär. Om till exempel en kurator på en skola skickar ut en enkät om elevernas psykiska hälsa ska eleverna känna att deras enkätsvar behandlas på ett säkert sätt.
Det finns ett stort antal krypteringsalgoritmer som skiljer sig åt vad gäller snabbhet, säkerhet och nyckelhantering. Tillverkaren av Java, Sun Microsystems, har utvecklat ett tillägg till Java, Java Cryptography Ex- tension15 (JCE) som återfinns i Javapaketet javax.crypto. I JCE finns bland annat krypteringsalgoritmerna Data Encryption Standard16 (DES), TripleDES, Advanced Encryption Standard17(AES) och Blowfish.
Vi valde att använda AES, även känd som Rijndael-algoritmen, ef-
tersom denna erbjöd stark kryptering och bland annat rekommenderades av amerikanska National Institute of Standards and Technology18 (NIST) [23]. Denna algoritm tillhör typen symmetriska algoritmer som använ- der samma nyckel för kryptering och dekryptering [23]. Detta förenklade handhavandet för oss när vi skulle kryptera och dekryptera data.
Vid användandet av en delad nyckel måste nyckeln finnas tillgäng- lig både vid kryptering och dekryptering. Om detta inte sker på samma
15URL:http://java.sun.com/products/jce/
16URL: http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.
17URL:http://csrc.nist.gov/CryptoToolkit/aes/rijndael/
5.5. Implementationsteori 37
plats måste nyckeln överföras på något sätt. Detta moment kan medföra en ökad risk. I vårt fall skall den aldrig förflyttas så därför blev detta pro- blem inte så stort för oss. Man kan lagra nyckeln krypterat i en så kallad
KeyStore19med ett lösenord som finns i Javakoden.
AES använder sig av en blockstorlek på 128 bitar och för varje 128-
bitars okrypterat datablock (klartext) som krypteras produceras ett 128 bi- tar stort krypterat datablock. Detta framgår även i figur 5.2 på sidan 37.
AES kan använda sig av nycklar som är 128, 192 respektive 256 bitar
[23]. Vi valde att kryptera hela filen med en 128-bitarsnyckel, eftersom de två större nyckelstorlekarna, 192 respektive 256 bitar, krävde modifiering av Javamiljön (eng.JRE). För att kunna använda de största nycklarna var
man tvungen att byta ut två så kallade policy-filer,local_policy.jar
och US_export_policy.jar, som man kunde ladda ner från Suns
webbplats20.
Figur 5.2: Schematisk skiss över hurAES-krypteringen går till.
Om personuppgifterna skyddas med ovanstående kryptering ansåg vi att vi uppfyllde Personuppgiftslagens krav på säker lagring, se stycke 5.4.
5.5.7 Inbjudningar
För att respondenterna ska uppmärksammas på att de är inbjudna att deltaga i en enkätundersökning måste en inbjudan skickas ut. E-
19URL:http://java.sun.com/j2se/1.5.0/docs/api/security/KeyStore.
html
postmeddelanden var det enda realistiska alternativet för att kunna nå målgruppen snabbt och effektivt. Vi förutsatte att alla respondenter har en e-postadress.
I inbjudningen måste det framgå hur respondenten ska gå tillväga för att svara på enkäten. I inbjudningen finns en länk samt inloggningsupp- gifter och ett personligt meddelande från personen som har skapat enkät- undersökningen.
En nackdel med e-postutskick är att det är svårt att skydda inlogg- ningsuppgifterna. Det finns lösningar för att skicka e-post krypterat men detta skulle ställa orimligt höga krav på respondenterna och försvåra pro- cessen avsevärt. En mindre säker, men enklare, metod är att skicka inbjud- ningen i form av två separata e-postmeddelanden där enbart inloggnings- uppgifterna återfinns i ett av e-postmeddelandena. Detta skulle troligen minska riskerna att någon obehörig kan besvara enkäten i en annan per- sons namn.
Vi valde att enbart skicka ett inbjudningsmeddelande för att det skulle vara enkelt att förstå för respondenten. Om en obehörig person svarar på enkäten kommer inte den avsedda respondenten att kunna logga in och denna skulle då kunna kontakta enkätundersökningens kontaktperson för att åtgärda problemet.
5.5.8 Generering av enkätformuläret
Vi såg två huvudalternativ för att generera enkätformuläret. Det ena var att i designapplikationen skapa formuläret och sedan föra över det till svarsapplikationen vid publicering. Det andra alternativet var att skapa enkätformuläret när respondenten skulle besvara enkäten. I detta fall mås- te den XML-fil som beskriver enkäten skickas med till svarsapplikationen
så att den kan omvandlas till ett formulär.
När man som i första alternativet ska generera formuläret i designap- plikationen skickas en färdig enkät till svarsapplikationen. Ett smidigt sätt att genereraHTML-kod från en XML-fil är att transformera XML-filen med
hjälp av enXSLT-mall. I denna mall är det även möjligt att infogaJSP-kod
varför vi även kan få ut enJSP-fil frånXML-filen. JSP-koden kan till exem-
pel underlätta vid validering av formulärdatat.
Ett sätt att generera enkäten i svarsapplikationen är att lägga enkätda- tat i en böna som skickas med begäran-objektet (eng.request) till en för alla
enkäter gemensamJSP. I bönan kan man lägga in olika sorters information
om enkäten, såsom titel och en lista med frågor. Frågorna skulle i sin tur kunna bestå av bönor som innehåller ett id-nummer, datatyp, validerings-
5.5. Implementationsteori 39
metod med mera.
Den generella JSP-filen genererar då formuläret i realtid utifrån enkät-
bönan. Denna lösning medför troligen att det blir enklare att göra avan- cerad validering. Lösningen är mer flexibel, till exempel kan enkätformu- läret enkelt visas på olika sätt, så som att dela upp enkätfrågorna mellan flera olika webbsidor eller visa frågorna som en PDF. Det enda som krävs
är att presentationslagret byts ut. Nackdelar med denna lösning är till ex- empel att fler diskåtkomster krävs när enkätformuläret skapas, vilket sker i realtid och inte vid publiceringen som blir fallet med det första lösnings- alternativet. Dessutom skulle enkätformuläret skapas för varje användare. Vi trodde att denna lösning skulle inverka negativt på prestandan, men den var ett intressant alternativ om ökad flexibilitet efterfrågades.
Vi valde att implementera det förstnämnda alternativet, på grund av prestandaskäl. Det borde inte krävas alltför lång tid för att byta modell.
5.5.9 Validering av formulärdata
Huvudalternativen för validering var att göra det på klientsidan eller på serversidan alternativt både och.
Vid validering på klientsidan kan respons ges även utan att indatat skickas till servern och kan därför upplevas snabbare. Det går även att va- lidera delar av indatat innan allt har skickas till servern. Den stora nack- delen med att validera på klientsidan är att man då måste ställa högre krav på klienten för att vara säker på att valideringen sker. Eftersom vi eftersträvade att inte skicka annat änHTML-kod till klienten hade vi svårt
att enbart validera indata på klientsidan. Däremot kan ett visst mervärde skapas genom en kombination av klient- och servervalidering, där server- valideringen är den enda som är nödvändig för att säkra korrekta indata och där klientvalideringen bidrar på andra sätt för att ytterligare hjälpa användaren.
Vid validering på serversidan måste datat ha skickats till servern innan respons på det kan ges tillbaka till klienten. Fördelen här är att utvecklaren har kontroll över att valideringen sker på ett korrekt sätt oberoende av klientmiljö. Kraven på klienten blir då mindre.
För klientsidan är JavaScript det vanligaste alternativet medan det finns många olika sätt att validera på serversidan. Struts skickade med ett valideringsramverk som var tänkt att underlätta validering både på klient- och serversidan men man kan även skriva egna valideringsmeto- der i bönorna.
ka krav på valideringsmetoderna. De statiskt genererade formulären är enklare att validera eftersom vi då vet vilka indata vi förväntar oss. I det dynamiska formuläret kan vi inte på förhand veta vilka indata som vi kan förvänta oss utan måste ta reda på det efter att formuläret skapats, under programmets körning.
Kapitel 6
Design av produkten
I detta kapitel beskriver vi hur vi har arbetat med designen av program- met.
6.1 Vision
Inledningsvis utformade vi ett funktionsschema för varje applikation, det vill säga designapplikationen respektive svarsapplikationen. De visar en- kelt och schematiskt vilken grundfunktionalitet som vi avser att imple- mentera.
I figur 6.1 på sidan 41 syns huvudfunktionaliteten i designapplikatio- nen. All hantering måste föregås av inloggningen, men därefter går det att välja mellan att skapa en ny enkätundersökning, redigera en befintlig samt att publicera en befintlig men tidigare opublicerad enkätundersök- ning. Efter att ett godtyckligt antal av dessa funktioner har utförts går det bra att logga ut.
Figur 6.1: Schema över ursprungliga funktionerna i designapplikationen. I figur 6.2 på sidan 42 visas det funktionsschema som gjordes för svars-
applikationen. Respondenterna loggar in, besvarar enkäten och blir däref- ter utloggade automatiskt.
Figur 6.2: Schema över ursprungliga funktionerna i svarsapplikationen.