Webbaserad kommunikationsklient för Radarspot KRISTOFER LÖFGREN

Webbaserad kommunikationsklient för Radarspot KRISTOFER LÖFGREN Examensarbete Stockholm, Sverige 2011

Webbaserad kommunikationsklient för Radarspot KRISTOFER LÖFGREN Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2011 Handledare på CSC var Serafim Dahl Examinator var Stefan Arnborg TRITA-CSC-E 2011:053 ISRN-KTH/CSC/E--11/053--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc

Referat Vi sköter kontakten med våra vänner på en rad olika sätt och har ofta en separat adressbok till varje tjänst, t.ex. adressboken i telefonen, kontaktlistan i Windows Live Messenger, Microsoft klient för direktmeddelanden, och adresslistan i vår eposttjänst. Radarspot ville konsolidera dessa adressböcker till en enda adressbok. Genom att sammanföra telefonens adressbok och listan över vänner i Microsoft Live Messenger skulle en levande adressbok skapas i telefonen där man kunde se närvarostatus på sina kontakter, det vill säga se vilka kontakter som är tillgängliga. Utifrån den sammanställda listan skulle man sedan välja hur man vill kontakta dem, via telefon, e-post eller direktmeddelande över Microsoft Live Messenger. Både e-post och Microsoft Live Messengermeddelanden skulle man kunna skicka och ta emot i Radarspots mobiltelefonklient. Radarspot ville även komplementera sin mobiltelefonklient med en webbaserad klient. Jag utvecklade en prototyp för denna webbaserade klient vilken fick motsvarande funktionalitet som mobiltelefonapplikationen som utvecklades parallellt. Det går att skapa en webbaserad kommunikationsklient men det är svårt att konkurrera med applikationer som körs lokalt på klienterna. En kommunikationsklient måste även fungera som en vanlig applikation när den inte används aktivt. Dvs. den måste meddela användaren på ett framgångsrikt sätt att ett nytt meddelande har inkommit, till exempel genom en ljudsignal och öppnanande av ett nytt meddelandefönster.

Abstract A Web Based Communication Client for Radarspot We manage the communication with our friends in multiple ways and often have a separate address book associated with each service, e.g. one address book in the cell phone, the friends list in Microsoft Live Messenger and the email contacts in our email service. Radarspot wanted to do was to consolidate these address books and friends lists to one single address book. By combining the address book in the cell phone and the list of friends in Microsoft Live Messenger Radarspot wanted to create a live address book where it was possible to se online status of contacts and choose how to contact them, by phone, email or by an instant message over the Microsoft Live Messenger network. Radarspot wanted a web based version of the address book as a complement to the application running on the cell phones. I developed a prototype of this web based address book that had the same functionality as the cell phone application that was developed in parallel. It is entirely possible to create a web based communication client but it is hard to compete with native applications running locally on the client machines. A web based communication client must also work in a similar way as a native application when it is not actively used, i.e. it must notify the user in a successful way that a new message has arrived either by sound, opening a new message windows or in some other way.

Innehåll 1 Introduktion 1 1.1 Radarspot................................. 1 1.2 Uppdrag och Mål............................. 2 2 Bakgrund och beskrivning 3 2.1 Befintliga klienter för direktmeddelanden................ 3 2.2 Arkitektur................................. 3 2.2.1 Överblick av nätverksarkitekturen............... 3 2.2.2 Teknisk beskrivning....................... 5 2.3 Systembeskrivning............................ 12 2.3.1 Grundläggande uppbyggnad................... 12 2.3.2 Säkerhet.............................. 14 2.3.3 Användargränssnittet...................... 14 2.4 Systemets funktionalitet......................... 14 2.4.1 Inställningar........................... 14 2.4.2 Kontaktlista............................ 14 2.4.3 Meddelanden........................... 16 2.4.4 Vänner och närvarostatus.................... 17 3 Slutsatser och rekommendationer 19 3.1 Slutsatser................................. 19 3.2 Rekommendationer............................ 20 Litteraturförteckning 21 Figurer 25 Bilagor 25 A Förkortningar 27

Kapitel 1 Introduktion Det finns i dagsläget många program för att skicka direktmeddelanden och närvarostatus mellan användare. Några exempel på dessa program är Microsoft Live Messenger, ICQ, AdiumX, Trillian och Pidgin. Det Radarspot ville göra var att koppla samman kontaktlistan som finns i telefonen med kontaktlistan/kontaktlistorna som finns i de olika programmen för direktmeddelanden. Målet var att sammanföra de olika kontaktlistorna till en enda. Kontaktlistan i telefonen och kontaktlistan i de olika programmen för direktmeddelanden kan innehålla olika sorts kontaktinformation för samma personer. Det Radarspot ville uppnå var att skapa en ny kontaktlista i sitt program vilken skulle vara en utbyggnad av den vanliga kontaktlistan i telefonen men med närvarostatus och möjlighet att skicka direktmeddelanden till sina kontakter. Radarspot utvecklade en klient för mobiltelefoner som läser in telefonens adressbok och synkroniserar den med en Radarspotserver på internet. Vidare kan mobiltelefonklienten skicka och ta emot direktmeddelanden och e-post via ovannämnda server. De direktmeddelanden som kan hanteras är interna Radarspotmeddelanden och meddelanden från Microsoft Live Messenger-nätverket. Mobilapplikationen uppdaterar kontinuerligt närvarostatus för alla kontakter i adressboken, dvs. den visar vilka kontakter som är inloggade på Radarspot eller Microsoft Live Messenger och vilka som inte är det. 1.1 Radarspot Radarspot är ett företag som utvecklat en kommunikationsapplikation för mobiltelefoner. Tanken var att användarna skulle kunna sköta all sin kommunikation från mobiltelefonen med denna kommunikationsapplikation. Det byggdes in stöd för Microsoft Live Messenger, e-post och Radarspots egna tjänst för direktmeddelanden. Förutom att skicka och ta emot meddelanden förmedlar tjänsten även närvarostatus på kontakterna i adressboken som har ett Radarspot- eller ett Microsoft Live Messenger-konto. 1

KAPITEL 1. INTRODUKTION 1.2 Uppdrag och Mål Som ett komplement till sin mobilapplikation ville Radarspot skapa en webbaserad applikation där funktionaliteten i mobilapplikationen också finns tillgängligt i ett webbgränssnitt. Uppgiften var att utveckla en prototyp av webbapplikationen som skulle ha samma funktion som mobilklienten. Mina mål var att inom ramen för exjobbet göra följande: Undersöka hur webbapplikationen kan vara uppbyggd och designa en logisk struktur för denna. Utveckla en fungerande prototyp av webbapplikationen. Huvuddelen av arbetet ska ligga på applikationslogiken och inte på gränssnittsdesignen. Krav på webbklienten: All kommunikation mellan webbapplikationen och Radarspotservern ska ske med XML-meddelanden i Radarspots egenutvecklade protokoll. Man ska kunna hantera kontakter och kontaktgrupper, dvs. skapa, radera och redigera dem. Adressboken skall kunna synkroniseras med Radarspotservern, troligtvis via SyncML. Det ska gå att se vilka kontakter som är inloggade och på vilka tjänster de är inloggade. Man ska kunna skicka och ta emot meddelanden via Radarspotservern. Man ska kunna se alla meddelanden som skickats till en kontakt i adressboken och alla meddelanden i en konversation. Man ska kunna bifoga bilder i png-format i meddelanden som skickas med tjänster som stöder det, t.ex. e-post och Microsoft Live Messenger. 2

Kapitel 2 Bakgrund och beskrivning 2.1 Befintliga klienter för direktmeddelanden I dagsläget finns det en mängd olika klienter för direktmeddelanden och närvarostatus. Några av de som körs lokalt på den egna datorn är Microsoft Live Messenger, AIM (AOL Instant Messenger), ICQ, Pidgin, Trillian och Adium. Dessutom finns det en stor grupp webbaserade klienter, t.ex. Meebo, KOOL IM och radiusim. Bland de klienter som körs på den egna datorn finns det sådana klienter som endast stöder sitt eget egenutvecklade protokoll som t.ex. Microsoft Live Messenger, AIM och ICQ. En majoritet av klienterna har dock stöd för flera olika protokoll, både öppna protokoll som XMPP och egenutvecklade som Microsoft Live Messenger-protokollet. [1], [3], [7], [15], [18], [21], [22], [28], [33], [40], [50]. 2.2 Arkitektur Detta kapitel beskriver den övergripande arkitekturen och beskriver de olika tekniker som används. 2.2.1 Överblick av nätverksarkitekturen Radarspots arkitektur består av tre olika komponenter, Radarspot Server, Radarspot Mobile och Radarspot Web. Radarspot Server är huvudkomponenten, det är via den all kommunikation med klienterna sker. Alla meddelanden, all närvarostatus och alla kontakter lagras i Radarsport Server och det är även den som sköter kommunikationen med Microsoft Live Messenger-nätverket och e-posthanteringen. Radarspot Mobile är den komponent som körs i mobiltelefonerna och ansluter till Radarspot Server över en dataanslutning. För synkronisering av adressboken kommunicerar mobilklienten med SyncML-meddelanden med en synkroniseringsserver i Radarspot Server. SyncML är en öppen standard för datasynkronisering. Användningen av SyncML för synkronisering av adressboken ger även telefoner utan Radarspot Mobile installerat möjligheten att synkronisera kontakter med Radarspot 3

KAPITEL 2. BAKGRUND OCH BESKRIVNING Radarspot Web Client Radarspot Mobile Client Radarspot Web Radarspot Server SyncML Server Microsoft Live Messenger Service Email Service Radarspot Database Figur 2.1. Översikt av Radarspots nätverksarkitektur. Server som då fungerar som en ren backup av kontaktlistan. All annan kommunikation mellan Radarspot Server och Radarspot Mobile sker med ett egenutvecklat protokoll. Radarspot Web är en webbaserad klient som är åtkomlig från en webbläsare och precis som Radarspot Mobile ansluter den till Radarspot Server. För hanteringen av kontaktinformation i Radarspot Web sker kommunikationen med Radarspot Server på det egenutvecklade protokollet istället för med SyncML. Figur 2.1 på sida 4 ger en överblick över nätverksarkitekturen. Radarspot Server består av ett par olika delar. Längst ner i hierarkin finns databasservern som hanterar all data i Radarspot. Till den ansluter både synkoniseringsservern (SyncML-servern) och applikationsservern (Radarspot Server). Det är synkroniseringsservern som sköter all synkronisering över SyncML och tillhandahåller ett synkroniseringsgränssnitt mot omvärlden. Allt annat hanteras av applikationsservern som tillhandahåller ett HTTP-protokoll mot omvärlden över vilket den kommunicerar med XML-meddelanden på ett egenutvecklat XML-protokoll. Vidare finns en Microsoft Live Messenger-tjänst och en e-posttjänst som kommunicerar med databasservern. Microsoft Live Messenger-tjänsten sköter all Microsoft Live Messenger-relaterad kommunikation och e-posttjänsten sköter all inkommande och utgående e-post. [25], [24] 4

2.2. ARKITEKTUR Samtidiga inloggningar Ett problem som behövde lösas var hur flera samtidiga inloggningar av samma användare skulle hanteras av systemet. En användare skulle kunna vara inloggad i Radarspot Mobile via flera olika mobilenheter och dessutom ha flera samtidiga inloggningar i Radarspot Web via olika datorer eller webbläsare. Att någon skulle vara inloggad på två olika mobilenheter höll vi på Radarspot för ganska sällsynt då de flesta endast har tillgång till en mobiltelefon. Att man skulle kunna vara inloggad på två olika webbläsare samtidigt var i detta scenario mycket troligare. Vi vill inte logga ut en användare efter en viss tids inaktivitet då vi ville att det skulle vara möjligt att ha ett webbläsarfönster öppet under en längre tidsperiod utan att användaren loggas ut vid inaktivitet. Den lösning som till slut valdes var en lösning där en användare kan vara inloggad med en session vardera på Radarspot Web och Radarspot Mobile men så fort en ny session skapas genom endera Radarspot Mobile eller Radarspot Web avslutas den tidigare sessionen för den tjänst där en ny session skapades. 2.2.2 Teknisk beskrivning Webbserver Det finns en mängd olika applikationsservrar som har stöd för Java Servlets och JavaServer Pages som är de tekniker i Java som Radarspot valt att använda. Bland de mer kända finns IBMs Web Sphere, BEAs WebLogic Server, SUNs referensimplementation GlassFish Application Server och Apache Tomcat från Apache Software Foundation. Valet av webbserver föll på Apache Tomcat då jag redan hade erfarenhet av den och att Radarspot Server redan använde Apache Tomcat som applikationsserver. Apache Tomcat från Apache Software Foundation är en servletmotor som stöder Java Servlets och JavaServer Pages specifikationerna. [6], [44], [26], [38], [42], [14], [41]. Lagring av data Radarspot Mobile-klienterna kan lagra kontaktinformation och meddelanden lokalt på klienten, denna möjlighet finns dock inte hos klienterna till Radarspot Web. En följd av detta blir att när något ska visas i webbklienten måste data hämtas från en server. Om till exempel alla uppgifter på en kontakt ska visas finns uppgifterna redan lagrade i Radarspot Mobile-klienten medan för Radarspot Web-klienten måste informationen hämtas från Radarspot Web eller Radarspot Server. Jag såg två olika lösningar framför mig av hur data till Radarspot Web-klienterna (webbläsarna) kunde lagras. Det första alternativet och den första implementationen jag valde var att ge Radarspot Web sin egen databas i vilken användarnas kontakter och meddelanden lagrades. Fördelen med detta var att jag i Radarspot Web kunde gå direkt till databasen för att hämta och spara kontakter, meddelande och närvarostatus på de användare som var inloggade via Radarspot Web. Nackdelen med denna lösning 5

KAPITEL 2. BAKGRUND OCH BESKRIVNING vara att Radarspot då skulle ha två olika databasen, den i Radarspot Server och den i Radarspot Web och dessa måste man hålla synkroniserade och enda sättet dessa två kunde synkroniserade var via vårt egenutvecklade XML-protokoll. Det skulle behövas en process som konstant låg och synkroniserade dessa två databaser. Den lösning jag valde istället var att inte lagra någon information alls i Radarspot Web utan alla information hämtade jag från Radarspot Server via vårt egenutvecklade XML-protokoll. Den stora fördelen med detta var att vi endast hade en databas som inte behövde synkroniseras. Nackdelen för Radaspot Web blev att alla förfrågningar tog lite längre tid och att jag behövde gå via vårt egenutvecklade protokoll för att hämta data istället för att gå direkt mot databasen. Med denna lösning skickade Radarspot Web vidare all data till Radarspot Server och agerade endast som en gateway till Radarspot Server som hanterade inloggade sessioner, serverade htmlsidor till webbläsarna och formaterade om vårt egenutvecklade XML-protokoll att vara anpassat till webbläsarna. Java Servlets och JSP Logiken i Radarspot Web är skriven i Java med Java Servlets och JSP (JavaServer Pages). JSP-koden integreras i HTML-sidorna precis som vilket annat skriptspråk som helst, t.ex. PHP och JavaScript. Skillnaden är att JSP-sidorna konverteras till Java Servlets som kompileras av servletmotorn. Kompileringen sker vid första anropet till JSP-sidan om de inte har kompilerats i förväg. JSP-koden integreras i HTML-sidor vilket gör den användbar för att styra hur data presenteras, till exempel kontaktlistan. Genom att använda Java Servlets kan man flytta ut logiken från HTML/JSP-sidorna till Java Servlets, till exempel alla anrop som behövs för att hämta kontaktlistan och närvarostatus för varje användare. Webbläsarkompabilitet Det krav som ställdes på webbsidorna var att det skulle fungera i de populäraste webbläsarna, vilket betydde Internet Explorer 6, Internet Explorer 7 och Mozilla Firefox. Kakor Kakor används av webbservrar och webbläsare för att särskilja användare och för att hålla reda på användarspecifik data under ett besök på webbservern. När en webbläsare efterfrågar en sida svarar webbservern med sidan men den kan också skicka med en så kallad kaka för den domän från vilken sidan kommer. Denna kaka innehåller domänen från vilken kakan kommer, ett namn på kakan samt ett utgångsdatum då webbläsaren ska kasta bort kakan. Själva innehållet i kakan som webbläsaren skickar till webbservern vid varje förfrågan är typiskt bara ett unikt id som webbservern använder för att identifiera användarens webbläsare. Följande exempel på en kaka innehåller bara ett unikt id: 6

2.2. ARKITEKTUR Name: sessionid Content: ABJeb18S11tloqxjGIFv0lVcqp Host: radarspot.se path: / Expires: 20 aug 2010 Webbläsaren skickar sedan tillbaka detta id i kakan vid varje förfrågan till den aktuella domänen. I webbservern används id:t för att hålla reda på användarspecifik information, till exempel vilka varor som ligger i användarens kundvagn i en webbutik och vilken användare som är inloggad eller om inloggning inte skett än. Session Hijacking Eftersom endast webbläsarens kaka används för att identifiera en användare på servern är det möjligt att ta över någon annans session på servern genom att skicka samma id till servern som för den användare man vill ta över sesssionen för. Ett korrekt skapat id tar för lång tid att gissa sig fram till (dvs. det finns inget sätt att räkna ut vad id:t är), problemet ligger istället i att det går att komma över ett aktivt id. Eftersom all trafik över HTTP skickas okrypterat kan i teorin alla se vilket id som används och bara kopiera det och på så sätt ta över en annan användares session. För att skydda Radarspot Web och dess klienter mot detta tvingar vi användarens webbläsare att använda HTTPS istället för HTTP. Detta gör att all kommunikation mellan Radarspot Web och användarens webbläsare krypteras och id:t inte går att läsa för någon som lyssnar på trafiken. För att detta ska fungera fullt ut får användarens webbläsare en ny kaka när HTTPS-seesionen börjar och den tidigare kakan som användes över HTTP invalideras eftersom det id som användes när HTTP användes kan vara äventyrat. All kommunikation mellan Radarspot Web och webbläsaren sker sen över HTTPS tills dess att användaren loggar ut. HTML och CSS Webbklientens användargränssnitt bygger på HTML (HyperText Markup Language) och CSS (Cascading Style Sheets). HTML används för att bygga upp strukturen och innehållet i sidorna som visas. CSS används för att bestämma hur HTMLinnehållet ska presenteras i webbläsarna. JavaScript JavaScript är ett skriptspråk som finns implementerat i alla moderna webbläsare. Tack vare implementationen av JavaScript tillåts webbservrar skicka kod till webbläsarna som exekveras i webbläsarna till skillnad från JSP som exekveras på servern som bara skickar resultatet av exekveringen till webbläsaren. För att skydda klienterna från skadlig JavaScript-kod exekveras JavaScript-koden i en begränsad miljö där den inte har rättigheter att komma åt filer på datorn som den exekveras på. Däremot kan JavaScript användas för att modifiera webbsidor som redan finns i webbläsaren och till att göra egna anrop till webbsidor. 7

KAPITEL 2. BAKGRUND OCH BESKRIVNING JavaScript-implementationerna i webbläsarna följer inte alltid samma standard, för att uppnå samma resultat måste ibland olika tillvägagångssätt användas. För att lösa detta problem har det uppkommit en mängd olika JavaScript-bibliotek som tillhandahåller funktioner som döljer alla dessa webbläsarspecifika funktioner och tillhandahåller ett enhetligt API (Application Programming Interface). Exempel på dess bibliotek är: Yahoo! User Interface Library (YUI) [51]. jquery [17]. Prototype [30]. Den stora fördelen med att använda sig av ett JavaScript-bibliotek är att de API:er som tillhandahålls fungerar på alla populära webbläsare och att de hålls uppdaterade när nya webbläsare kommer ut och när buggar upptäcks. [16], [30], [17], [51]. Ajax Ajax, Asynchronous JavaScript and XML, är ett samlingsnamn för ett antal olika tekniker som kan användas för att bygga interaktiva webbapplikationer. Ajax möjliggör för webbapplikationer att hämta data asynkront från servern vilket innebär att efter att den initiala sidan har laddats hämtas mer information som kan användas till att uppdatera den befintliga sidan som redan har hämtats. Följande tekniker kan användas för att utföra asynkron kommunikation med en server: HTML eller XHTML (Extensible Hypertext Markup Language) och CSS (Cascading Style Sheets) för presentationen. DOM (Document Object Model) för att dynamiskt visa och interagera med data. XML (Extensible Markup Language) och XSLT (Extensible Stylesheet Language Transformations) för att byta, manipulera och visa data. XMLHttpRequest för den asynkrona kommunikationen. JavaScript för att sammanfoga de ovanstående teknikerna. Benämningen Ajax innefattar idag en bredare mängd olika tekniker. XML och XSLT används inte alltid för utbyte och manipulation av data. Alternativ som JavaScript Object Notation (JSON), ren text och förformaterad HTML används också. [4], [5]. Extensible Markup Language Extensible Markup Language är mer känt under förkortningen XML. XML är ett generellt märkspråk som utgör en delmängd av det mer komplexa Standard Generalized Markup Language, SGML. XHTML, XSL (Extensible Stylesheet Language), 8

2.2. ARKITEKTUR SMIL (Synchronized Multimedia Integration Language) och RSS (Really Simple Syndication) är alla baserade på XML. World Wide Web Consortium, W3C, är ett konsortium bestående av drygt 500 medlemmar från ledande industrier, forsknings- och utvecklingsinstitut, standardiseringsorgan och regeringar samt EU. W3C arbetar med att utveckla protokoll, standarder och programvara för internet. W3C ligger bakom specifikationerna för bland andra CSS, HTML, XHTML, XML. [32], [2], [43], [12], [49]. Parsning av XML Kommunikation mellan Radarpot Server, Radarspot Web och Radarspot Mobile sker på ett egenutvecklat XML-protokoll. För att säkerställa att alla inkommande och utgående XML-meddelanden är korrekta valideras de mot ett XML-schema. Det finns ett par olika språk för att bygga XML-scheman. XML Schema är ett samlingsnamn för alla olika språk som finns för att skapa XMLscheman, men det är också namnet på XML-schemaspråket från W3C. För parsning av XML finns det två huvudsakliga API:er, trädbaserade respektive händelsebaserade API:er. För fallet med ett trädbaserad API byggs en intern trädstruktur (DOM, Document Object Model) upp som representerar XMLdokumentet. Applikationer som använder trädbaserade parsers kan sedan traversera trädstrukturen. För händelsebaserade API:er finns det två olika metoder, push parsers respektive pull parsers. En applikation som använder en push parser registrerar ett antal olika händelser (t.ex. vad som ska hända när en viss start eller slut-tag påträffas) som kopplas till de olika element som finns i ett XML-meddelande. När parsern stöter på ett element till vilket det finns en registrerad händelse anropas denna. Ett exempel på en push parser är SAX (Simple API for XML). Vid användandet av en pull parser efterfrågar applikationen hädelser från parsern istället för att registrera händelser som ska anropas när olika element i dokumentet påträffas. En pull parser kan ses som en pekare in i XML-dokumentet som applikationen för frammåt i dokumentet genom att efterfråga element i det. StAX (Streaming API for XML) är ett exempel på en pull parser. I en push parser meddelar parsern applikationen när den stöter på ett nytt element, t.ex. en ny artikel i ett XML-meddelande som följer DTD-schemat på sidan 11. En applikation som använder en pull parser frågar istället parsern efter artikelelementet. [29], [19], [35], [39] Document Type Definition Document Type Definition, DTD, är ett XMLschemaspråk för att definiera en struktur med vilka element, attribut och entiteter som är tillåtna eller obligatoriska i ett XML-meddelande. Elementen är de huvudsakliga byggstenarna i XML-dokument. I nedanstående exempel finns ett meddelandeelement. <meddelande>någon text</meddelande> Attribut ger extra information om element. I nedanstående exempel har meddelandeelementet ett attribut som anger priotitet. 9

KAPITEL 2. BAKGRUND OCH BESKRIVNING <meddelande prioritet="hög">någon text</meddelande> Entiteter är variabler som används för att definiera förkortningar eller specialtecken. Ett exempel i HTML är entiteten amp som ger en ampersand i renderingen av en HTML-sida. En entitet anropas genom den föregås av en ampersand och efterföljs av ett semikolon. Exempel: <meddelande>karlsson & CO</meddelande> Vid rendering presenteras meddelandet: Karlsson & CO DTD-exempel Nedan följer ett DTD-exempel som använder element, attribut och entiteter. Huvudelementet är NEWSPAPER som måste ha en eller flera underelement av typen ARTICLE. Varje ARTICLE element måste i sin tur ha precis ett underelement av följande typer: HEADLINE, BYLINE, LEAD, BODY, NO- TES. Elementet ARTICLE måste även ha attributet AUTHOR, det kan dessutom ha EDITOR, DATE och EDITION, men de är inte nödvändiga. Vidare har tre entiteter definierats: NEWSPAPER, PUBLISHER och COPYRIGHT. <!DOCTYPE NEWSPAPER [ <!ELEMENT NEWSPAPER (ARTICLE+)> <!ELEMENT ARTICLE (HEADLINE,BYLINE,LEAD,BODY,NOTES)> <!ELEMENT HEADLINE (#PCDATA)> <!ELEMENT BYLINE (#PCDATA)> <!ELEMENT LEAD (#PCDATA)> <!ELEMENT BODY (#PCDATA)> <!ELEMENT NOTES (#PCDATA)> <!ATTLIST ARTICLE AUTHOR CDATA #REQUIRED> <!ATTLIST ARTICLE EDITOR CDATA #IMPLIED> <!ATTLIST ARTICLE DATE CDATA #IMPLIED> <!ATTLIST ARTICLE EDITION CDATA #IMPLIED> <!ENTITY NEWSPAPER "Vervet Logic Times"> <!ENTITY PUBLISHER "Vervet Logic Press"> <!ENTITY COPYRIGHT "Copyright 1998 Vervet Logic Press"> ]> Exempel från W3 Schools, http://www.w3schools.com/dtd/dtd_examples.asp (2009-01-17). [11], [10]. 10

2.2. ARKITEKTUR W3C XML Schema W3C XML Schema är även känt som XML Schema Definition (XSD) är ett alternativ till DTD. W3C XML Schema är XML-baserat till skillnad från DTD. Precis som i DTD definieras vilka element och attribut som kan användas och i vilka kombinationer. W3C XML Schema har även stöd för datatyper, vilket innebär att innehållet i ett element eller attribut kan valideras mot en datatyp. W3C XML Schema har initialt stöd för 19 primitiva datatyper däribland: boolean, string, double, date och time. Fler datatyper kan skapas genom att kombinera de existerande på tre olika sätt: Restriktion - Begränsa mängden godkända värden. List - Tillåt en sekvens av värden. Union - Tillåter ett flertal datatyper. Nedan följer ett exempel på ett element med namnet age. Elementet har en datatyp av typen heltal och en restriktion på mängden heltal som är tillåtna. Endast heltal från och med 0 till och med 120 är tillåtna. [47], [46]. <xs:element name="age"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:mininclusive value="0"/> <xs:maxinclusive value="120"/> </xs:restriction> </xs:simpletype> </xs:element> Andra XML-schemaspråk Förutom DTD och XML Schema finns det ett antal andra språk för att skriva scheman för XML på. Några av dem är: RELAX NG, REgular LAnguage for XML Next Gereration, är precis som W3C XML Schema XML-baserat. RELEAX NG tillhandahåller även en alternativ kompakt syntax som inte är XML-baserad. DDML, Document Definition Markup Language, är en omformulering av DTD till XML. Den har inget stöd för datatyper som W3C XML Schema. SOX, Schema for Object-Oriented XML, är tillsammans med DDML en av föregångarna till W3C Schema och RELAX NG. Schematron är ett regelbaserat valideringsspråk som bygger på krav/påståenden (assertions) angående vilken struktur som tillåts i XML-dokumenten. DSD, Document Structure Description, är designat för att vara enkelt och lätt att förstå men samtidigt vara kraftfullare än DTD och W3C Schema. [8], [9], [34], [47], [36], [37], [48]. XMLBeans XMLBeans är ett Java-till-XML ramverk för konvertering av XMLmeddelanden till instanser av Java-klasser och tvärtom. Utifrån ett W3C XML 11

KAPITEL 2. BAKGRUND OCH BESKRIVNING Schema genereras Java-klasser som motsvarar beskrivningen i XML-schemat. Utifrån en struktur skapad med instanser av dessa XMLBeans-genererade klasser genereras sedan korrekt XML som stämmer överens med det W3C XML Schema som användes av XMLBeans för att skapa Java-klasserna. Genom att skicka in ett XML-meddelande till de XMLBeans genererade klasserna valideras det och en objektstruktur av Java-klasser genereras. XMLBeans är ett trädbaserat API. [45]. kxml kxml är en lättviktig implementation av en XMLPull Parser. kxml har i första hand utvecklats för miljöer som har begränsningar vad det gäller minne, t.ex. Applets, PersonalJava och MIDP-enheter. PersonalJava är en Javaversion (baserad på Java 1.1.8) för mobila och inbyggda system. MIDP, Mobile Information Device Profile, är en specifikation för att använda Java i mobiltelefoner och PDA:er (Pesonal Digital Assistant). kxml är ett händelsebaserat API. [19]. 2.3 Systembeskrivning Syftet med systemet är att skapa ett webbgränssnitt till ett webbaserat system för direktmeddelanden och närvarostatus mellan användare. Detta kapitel beskriver hur systemet är uppbyggt. 2.3.1 Grundläggande uppbyggnad I botten finns det befintliga systemet (Radarspot Server) för direktmeddelande och närvarostatus. Alla funktioner i detta system är tillgängliga genom ett eget API som bygger på XML-meddelanden. Radarspots webbapplikation som kallas Radarspot Web är ett webbgränssnitt för direktmeddelanden och närvarostatus för användarna. Radarspot Web kommunicerar med Radarspot Server via meddelanden i Radarspots egna XML-protokoll. När en användare försöker autentisera sig mot Radarspot Web skickas ett meddelande till Radarspot Server med användarens inloggningsuppgifter. Om användarens inloggningsuppgifter är korrekta kommer både Radarspot Web och Radarspot Server hålla reda på användarens session. För att användaren sen ska få alla sina meddelanden och närvarostatus på sina vänner efterfrågar Radarspot Web den informationen från Radarspot Server. Detta sker automatiskt med tekniken Ajax, som beskrevs i arkitekturavsnittet på sida 8. Radarspot Web måste alltså efterfråga all information från Radarspot Server, ingenting kommer utan en förfrågan. Frekvensen med vilken t.ex. närvarostatus efterfrågas från Radarspot Server avgör hur kvick tjänsten upplevs. När Radarspot Web tar emot informationen i form av XML-meddelanden från Radarspot Server analyseras svaret och formateras för att passa det grafiska utseendet på Radarspot Web. Figur 2.2 på sida 13 visar ett sekvensdiagram för ett anrop från användarens webbläsare för att hämta närvarostatus på användarens kontakter. En beskrivning av de olika stegen följer i listan nedan. 12

2.3. SYSTEMBESKRIVNING Klient Radarspot Web Radarspot Server 1: GetOnlineStatuses() 2: VerifyLoggedIn() 3: GetOnlineStatuses ForContacts() 4: Verify_ LoggedIn() 6: Formated list of online statuses 5: Return list of online statuses Figur 2.2. Sekvensdiagram över en närvarostatusförfrågan. 1. Användarens webbläsare gör ett anrop till Radarspot Web med hjälp av Ajax där närvarostatus för användarens vänner efterfrågas. 2. Radarspot Web verifierar att användaren är inloggad. 3. Radarspot Web skapar ett XML-meddelanden där användarens vänners närvarostatus efterfrågas från Radarspot Server. 4. Radarspot Server verifierar att användaren är inloggad. 5. Radarspot Server returnerar närvarostatus för användarens vänner till Radarspot Web som ett XML-meddelande. Radarspot Web formaterar användarnas närvarostatus för att passa i webbgränssnittet på klienten. 6. Klienten får svar på anropet som efterfrågade användarens vänners närvarostatus och visar det för användaren. Genom Radarspot Server kan användaren skicka och ta emot direktmeddelanden både internt mellan Radarspotanvändare och mellan Microsoft Live Messengerkonton, om Radarspot har fått tillgång till användarens Microsoft Live Messengeruppgifter. Via Radarspot Server går det också att skicka och ta emot e-post om Radarspot har fått tillgång till inloggningsuppgifter för ett e-postkonto. För klienterna Radarspot Web och Radarspot Mobile ser alla dessa meddelanden likadana ut oberoende av vilken tjänst som används i bakgrunden. Mellan Radarspotvänner kommuniceras även närvarostatus för att det ska gå att se i kontaktlistan om en vän är inloggad eller inte. Radarspot tar även emot och skickar närvarostatus till Microsoft Live Messenger-nätverket. Har Radarspot fått tillgång till ett Microsoft Live Messenger-konto kan Radarspot hålla reda på vänner som är inloggade och visa den informationen i Radarspotklienten. 13

KAPITEL 2. BAKGRUND OCH BESKRIVNING 2.3.2 Säkerhet När användaren loggar in på Radarspot Web tvingas HTTP-sessionen över till HTTPS där all data automatiskt krypteras med SSL (Secure Socket Layer). Användaren hålls kvar i HTTPS-sessionen tills utloggning sker. All kommunikation mellan klienten och Radarspot Web sker alltså krypterat. Radarspot Web sparar inte någon klientdata, det enda som sparas under sessionen är användarens webbläsarkaka till vilken användarnamnet är kopplat och användarens kaka mot Radarspot Server som Radarspot Web får vid inloggningen där. Den används av Radarspot Server för att hålla koll på inloggade användare. När en användare loggar på via Radarspot Web får användarens webbläsare en kaka från Radarspot Web, denna kaka används för att identifiera användaren i Radarspot Web. Vid inloggning skapar Radarspot Web en ny session mot Radarspot Server för den inloggade användaren. Radarspot Web får då i sin tur en kaka av Radarspot Server som används av Radarspot Server för att hålla koll på inloggade användare. Denna kaka från Radarspot Server kopplas ihop med användarens session i Radarspot Web så att rätt kaka används i Radarspot Web för att efterfråga meddelanden, närvarostatusuppdateringar och annan information av Radarspot Server. [27] 2.3.3 Användargränssnittet Användargränssnittet i Radarspot Web bygger på HTML och CSS. För att inte endast använda statiska sidor används Ajax för att dynamisk ändra innehållet på sidor som visar närvarostatus och meddelanden för användarna. 2.4 Systemets funktionalitet 2.4.1 Inställningar Alla Radarspotanvändare kan automatiskt kommunicera med andra Radarspotanvändare genom de konton som skapas vid användarregistreringen till tjänsten. Via Radarspot Web finns möjligheten att tillhandahålla inloggningsuppgifter för Microsoft Live Messenger och ett e-postkonto. Om Radarspot får tillgång till dessa uppgifter öppnas även möjligheten att skicka och ta emot Microsoft Live Messengeroch e-postmeddelanden. Figur 2.3 på sida 15 visar vissa av de inställningar som går att göra i klienten. 2.4.2 Kontaktlista Radarspot tillhandahåller en kontaktlista där det går att koppla samman Radarspotanvändarnamn, e-postadress, Microsoft Live Messenger-användarnamn, telefonnummer och adressuppgifter till en och samma kontakt. Via Radarspot Web går det att hantera alla uppgifter i kontaktlistan samt att addera och radera kontakter. Figur 2.4 på sida 16 visar kontaktlistan med aktuell närvarostatus på kontakterna. 14

2.4. SYSTEMETS FUNKTIONALITET Figur 2.3. Användarinställningar. 15

KAPITEL 2. BAKGRUND OCH BESKRIVNING Figur 2.4. Kontaktlistan. Figur 2.5. Meddelanden. 2.4.3 Meddelanden Via Radarspot Web finns möjligheten att skicka, ta emot och radera meddelanden som har skickats med någon av de aktiverade tjänsterna (Radarspot, Microsoft Live Messenger och e-post). Figur 2.5 på sida 16 visar de senaste inkomna och skickade meddelandena. 16

2.4. SYSTEMETS FUNKTIONALITET Figur 2.6. Lägg till ny kontakt. 2.4.4 Vänner och närvarostatus Närvarostatus visas för alla Radarspot-vänner och Microsoft Live Messenger-vänner. Nya Radarspot-vänner kan adderas direkt via webbgränssnittet i Radarspot Web. Nya Microsoft Live Messenger-vänner kan inte adderas via Radarspot utan de måste skapas via en annan klient, Radarspot importerar sedan vänlistan från Microsoft Live Messenger-nätverket. Är både Radarspot-användarnamn Microsoft Live Messenger-användarnamn kopplat till en och samma kontakt visas status för den tjänst där användaren är mest nåbar. T.ex. om användaren har statusen borta på Radarspot men online på Microsoft Live Messenger visas statusen online i Radarspot Web. Figur 2.6 på sida 17 visar sidan för att lägga till en ny kontakt. 17

Kapitel 3 Slutsatser och rekommendationer 3.1 Slutsatser Det gick att skapa en webbaserad meddelandeklient som hade motsvarande funktionalitet som Radarspots mobilklient. Det som webbklienten förlorar på är att den har en bit kvar till att konkurrera med en fristående applikation som körs lokalt hos användaren och med den integrering i operativsystemet det erbjuder. En meddelandeklient måste även fungera som en vanlig applikation när den inte används aktivt. Dvs. den måste meddela användaren på ett framgångsrikt sätt att ett nytt meddelande har inkommit, till exempel genom en ljudsignal och öppna ett nytt meddelandefönster. Med de webbläsare som fanns tillgängliga vid utförandet av examensarbetet kraschade hela webbläsaren om en av de öppna webbläsartabbarna fick webbläsaren att krascha. Idag finns det webbläsare som hanterar varje webbläsartabb som en separat process och en krasch i en webbläsartabb ska inte krascha hela webbläsaren. Det finns numera applikationer som Prism från Mozilla Labs och Chrome från Google med vilka det går att skapa fristående applikationer av webbapplikationer. Till exempel går det att skapa en applikation som öppnar adressen http://www.meebo.com i ett fristående fönster och hanterar den som en fristående applikation. Ett annat problem som aktualiserades var fördröjningen i webbklienten. Detta märktes inte av förrän en meddelandesession hade startats då långsamma uppdateringar till meddelandesessionen fick applikationen att kännas seg. Detta berodde på att meddelandehanteringen krävde att klienten efterfrågade nya meddelanden från Radarspot Web som i sin tur kollade med Radarspot Server om det fanns några nya meddelanden. För att delvis komma runt dessa problem kan en variabel pollningstid sättas, dvs. direkt efter att ett meddelande har mottagits eller skickats efterfrågar klienten uppdateringar med ett mycket kort tidsintervall vilket sedan avtar till ett mer långsammare intervall varefter tiden går och inga nya meddelanden skickas eller tas emot. En bättre lösning torde vara att ersätta pollningen med push, dvs. klienten har en öppen anslutning till servern och när ett meddelande kommer till 19

KAPITEL 3. SLUTSATSER OCH REKOMMENDATIONER serverns skickas det direkt till klienten utan att det behöver efterfrågas. All trafik mellanlandade i Radarspot Web, genom att tillåta klienten att hämta meddelanden och annan information direkt från Radarspot Server och att ersätta meddelandeprotokollet med XMPP skulle klienten upplevas som snabbare och även fristående klienter som stöder XMPP skulle kunna ansluta till Radarspots server. Eftersom Radarspot Web inte meddelades när nya meddelanden eller närvarostatus uppdaterades kunde inte sådan information lagras i en cache hos Radarspot Web och på så sätt snabba upp svarstiderna utan all den information var Radarspot Web tvungen att hämta från Radarspot Server med jämna mellanrum även om ingenting hade förändrats. Idag börjar vi se mobiltelefoner som integrerar alla våra olika adressböcker i en och samma adressbok. I t.ex. Nokias N900 finns bl.a. möjligheten att koppla sitt Skype och XMPP-konto till adressboken och därigenom uppnår man den form av konsoliderad adressbok Radarspot försökte skapa. [31], [13], [21], [20], [23] 3.2 Rekommendationer Radarspot kom en bit på vägen med sin idé om en online-adressbok som kopplar samman all kontaktinformation som finns tillgänglig för en och samma kontakt i en gemensam adressbok och erbjuder kommunikationsmöjligheter med varje kontakt på alla de tjänster som finns registrerade för kontakten. Jag tror att det finns en plats för den typ av online-adressbok som Radarspot strävade efter, men jag tror att just deras förslag inte var den bästa lösningen på grund av avsaknaden av integration med andra tjänster och att det som Radarspot försökte vara unika med (meddelanden till telefonen och en enhetlig adressbok) inte var tillräckligt unik och för knepigt att administrera. Beroende på användarbeteendet ser jag inga större tekniska problem med en webbaserad chattklient. Både Gmail och Facebook har integrerade chattklienter och jag tror det är väldigt personlig hur de passar in i användarbeteendet. Själv låter jag min chattklient ligga i bakgrunden och förlitar mig på att jag blir meddelad på något sätt att ett nytt meddelande har inkommit. I t.ex. Gmails klient syns ett inkommande meddelande endast i webbläsarfönstret. Jag tror även en närmare integration med operativsystemet är önskvärt. I t.ex. mejlprogrammet och i adressboken i Mac OS X kan se om en kontakt är online via XMPP eller inte om det inbygda chattprogrammet (ichat) är igång samtidigt. 20

Litteraturförteckning [1] Adium. Senast nådd: 2011-03-01. http://adium.im/ [2] C. M. Sperberg-McQueen, Lou Burnard, A Gentle Introduction to SGML. Senast nådd: 2011-03-02. http://www.isgmlug.org/sgmlhelp/g-index.htm [3] AIM, AOL Instant Messenger. Senast nådd: 2011-03-01. http://www.aim.com/ [4] Jesse James Garrett, Ajax: A New Approach to Web Applications. Senast nådd: 2011-03-01. http://www.adaptivepath.com/ideas/essays/archives/000385.php [5] Ajax Tutorial (Asynchronous Javascript + XML). Senast nådd: 2011-03-01. http://www.xul.fr/en-xml-ajax.html [6] The Apache Software Foundation. Senast nådd: 2010-05-19. http://www.apache.org [7] Comparison of instant messaging clients, Wikipedia. Senast nådd: 2010-03-07. http://en.wikipedia.org/wiki/comparison_of_instant_messaging_clients [8] Document Definition Markup Language (DDML) Specification, Version 1.0. Senast nådd: 2011-03-01. http://www.w3.org/tr/note-ddml [9] DSD, Document Structure Description. Senast nådd: 2010-05-19. http://www.brics.dk/dsd/ [10] DTD, Document Type Definition. Senast nådd: 2010-05-19. http://www.w3schools.com/dtd/default.asp [11] Extensible Markup Language (XML) 1.0 (Fifth Edition). Senast nådd: 2011-03-01. http://www.w3.org/tr/rec-xml/#dt-doctype 21

LITTERATURFÖRTECKNING [12] Extensible Markup Language (XML). Senast nådd: 2010-05-19. http://www.w3.org/xml/ [13] Google Chrome. Senast nådd: 2010-05-19. http://www.google.com/chrome/ [14] GlassFish. Senast nådd: 2011-03-01. http://glassfish.java.net/ [15] ICQ. Senast nådd: 2011-03-01. http://www.icq.com/en.html [16] JavaScript, Mozilla Developer Network. Senast nådd: 2010-03-02. https://developer.mozilla.org/en/javascript [17] jquery. Senast nådd: 2010-05-19. http://jquery.com/ [18] KOOL IM. Senast nådd: 2010-03-07. http://www.koolim.com [19] kxml. Senast nådd: 2010-05-19. http://kxml.sourceforge.net/ [20] Maemo, Nokia. Senast nådd: 2010-11-01. http://maemo.nokia.com/features/conversations/ [21] Meebo. Senast nådd: 2010-03-07. http://www.meebo.com [22] Microsoft Live Messenger 2011. Senast nådd: 201!-03-01. http://explore.live.com/windows-live-messenger?os=mac [23] My-Maemo. Senast nådd: 2010-11-01. http://my-maemo.com/compare.php [24] OMA Data Synchronization V1.2.2, Open Mobile Alliance. Senast nådd: 2011-03-02 http://www.openmobilealliance.org/technical/release_program/ds_v1_2_2.aspx [25] Open Mobile Alliance. Senast nådd: 2010-08-16 http://www.openmobilealliance.org/ [26] Open Source Web Servers in Java. Senast nådd: 2010-05-19. http://java-source.net/open-source/web-servers [27] Overview of SSL/TLS Encryption, Microsoft. Senast nådd: 2011-03-02. http://technet.microsoft.com/en-us/library/cc781476(ws.10).aspx 22

LITTERATURFÖRTECKNING [28] Pidgin. Senast nådd: 2011-03-01. http://www.pidgin.im/ [29] Ian Kaplan, Processing XML with the XML Pull Parser. Senast nådd: 2010-05-19. http://www.bearcave.com/software/java/xml/xmlpull.html [30] Prototype JavaScript Framework. Senast nådd: 2010-05-19. http://www.prototypejs.org/ [31] Prism. Senast nådd: 2010-05-19. http://mozillalabs.com/prism/ [32] Overview of SGML Resources, W3C. Senast nådd: 2011-03-02. http://www.w3.org/markup/sgml/ [33] radiusim Senast nådd: 2010-05-19 http://www.radiusim.com/ [34] RELAX NG. Senast nådd: 2010-03-1902. http://relaxng.org/ [35] SAX, Simple API for XML. Senast nådd: 2011-03-02. http://www.saxproject.org/ [36] Schema for Object-Oriented XML 2.0, W3C. Senast nådd: 2011-03-02. http://www.w3.org/tr/note-sox/ [37] Schematron. Senast nådd: 2011-03-02. http://www.schematron.com/ [38] Jason Hunter, Servlet Engines. Senast nådd: 2010-05-19. http://www.servlets.com/engines/ [39] Lara D Abreo, StAX: DOM Ease with SAX Efficiency. Senast nådd: 2011-03-12. http://www.devx.com/java/article/30298/0 [40] Trillian. Senast nådd: 2011-03-01. httphttp://www.trillian.im/ [41] WebLogic Server. Senast nådd: 2011-03-01. http://www.oracle.com/us/products/middleware/applicationserver/index.html [42] WebSphere software. Senast nådd: 2011-03-01. http://www-01.ibm.com/software/websphere/ [43] The World Wide Web Consortium. Senast nådd: 2010-05-19. http://www.w3.org/ 23

LITTERATURFÖRTECKNING [44] Joseph Ottinger, What is an App Server?. Senast nådd: 2011-03-01. http://www.theserverside.com/news/1363671/what-is-an-app-server [45] XMLBeans. Senast nådd: 2010-05-19. http://xmlbeans.apache.org/ [46] XML Schema. Senast nådd: 2010-05-19. http://www.w3schools.com/schema/ [47] XML Schema, W3C. Senast nådd: 2010-05-19. http://www.w3.org/xml/schema [48] Robin Cover, XML Schemas, Cover Pages. Senast nådd: 2011-03-03. http://xml.coverpages.org/schemas.html [49] XML Tutorial. Senast nådd: 2010-05-19. http://www.w3schools.com/xml/default.asp [50] XMPP, Extensible Messaging and Presence Protocol. Senast nådd: 2010-03-07. http://www.xmpp.org [51] YUI (Yahoo! User Interface) Library. Senast nådd: 2010-05-19. http://developer.yahoo.com/yui/ 24

Figurer 2.1 Översikt av Radarspots nätverksarkitektur................. 4 2.2 Sekvensdiagram över en närvarostatusförfrågan............... 13 2.3 Användarinställningar............................. 15 2.4 Kontaktlistan................................. 16 2.5 Meddelanden.................................. 16 2.6 Lägg till ny kontakt.............................. 17 25

Bilaga A Förkortningar Ajax API CSS DOM DTD HTML HTTP HTTPS JSON JSP MIDP PDA RSS SAX SGML SMIL StAX SyncML SSL W3C XHTML XML XMPP XSD XSL XSLT Asynchronous JavaScript and XML Application Programming Interface Cascading Style Sheets Document Object Model Document Type Definition Hypertext Markup Language Hypertext Transfer Protocol Hypertext Transfer Protocol Secure JavaScript Object Notation JavaServer Pages Mobile Information Device Profile Pesonal Digital Assistant (Handdator) Really Simple Syndication Simple API for XML Standard Generalized Markup Language Synchronized Multimedia Integration Language Streaming API for XML SyncML Är en öppen standard baserad på XML för fjärrsynkronisering Secure Socket Layer World Wide Web Consortium Extensible Hypertext Markup Language Extensible Markup Language Extensible Messaging and Presence Protocol XML Schema Definition Extensible Stylesheet Language Extensible Stylesheet Language Transformations 27

TRITA-CSC-E 2011:053 ISRN-KTH/CSC/E--11/053-SE ISSN-1653-5715 www.kth.se