Provision

En så kallad provision är egentligen till för att synkronisera en policy [6]. Vilket inte används i min implementation. Istället kontrolleras här att alla nödvändiga mappar finns på servern (som skapas annars) samt skapar synkroniseringsfilen. En annan anledning till att metoden är implementerad är att man kan spara lite mer detaljerad information som klienten skickar i samband med provisionen. Till exempel version av klientens operativsystem.

Klient Server

Be om Policy

Presentera Policy

Bekräfta accepterande av Policy

Returnera PolicyKey

Figur 4.2:Hämtning av en policynyckel.

En provision går till så att klienten begär att få tillgång till Exchange Serverns policy. Exchange Servern returnerar sedan eventuell policy (eller meddelar att det saknas policy på Exchange Servern). Därefter skickar klienten information till Exchange Servern om policyn uppfylldes eller inte.

Till sist svarar Exchange Servern med en bekräftelse, och om det finns, en perma- nent policynyckel som klienten ska använda sig av i framtida förfrågningar.

4.2 Implementation av Exchange ActiveSync 19

4.2.2

Mappsynkronisering

Om provisionen lyckas görs ett nytt försöka att ladda ner mappar från Exchange Servern. Det sker genom att klienten hämtar mappens unika id på servern, vilken sedan alltid används för att referera till en specifik mapp.

En mappsynkronisering kommer ske varje gång en kalender läggs till, ändras el- ler tas bort. För att avgöra om en mappsynkronisering ska ske kontrolleras det regelbundet, i samband med kalendersynkronisering och ping, om det är någon skillnad mellan synkroniserade kalendrar i synkroniseringsfilen jämfört med ex- isterande kalendrar på CloudMe.

4.2.3

Kalendersynkronisering

Nästa steg är att synkronisera kalenderhändelser i en specifika kalendrar. Klien- ten kommer meddela Exchange Servern om vilka kalendrar som önskas synkro- niseras. Samtidigt som klienten begär uppdateringar av kalenderhändelser från Exchange Servern kan ett meddelande om uppdateringar av kalenderhändelser gjorda på klienten skickas med.

I synkroniseringsfilen finns information om vilka kalenderhändelser som har syn- kroniserats och en tidsstämpel då en viss kalender senast synkroniserades. Implementationen använder sig av tidsobjektet boost::posix_time::ptime för att lätt kunna jämföra två tidsstämplar med normala jämförelseoperander i C++. För att hämta ut information ur den inkommande XML-datan använder jag mig av paketet libxml2. Genom en wrapper skriven i C++ kallar jag på metoder som bland annat skapar ett XML-objekt, som kan användas för tolka XML-dokumentet, i libxml2. Därefter hämtar jag genom olika metoder ut innehållet i till exempel. ett XML-element eller ett XML-attribut.

En annat metod, som Xcerion senare valde att fortsätta med, är att använda XSLT för att transformera data mellan klient och Exchange Server samt vice versa. Be- roende från vilket håll datan kommer (dvs. klient eller Exchange Server) behövs det ett eget XSLT schema.

Fördelen med XSLT att det går att skapa dynamiska regler för XML dokument samt ger ökad läsbarhet då det blir mindre C++ kod. Anledningen till att jag använde libxml2 var dock att jag inte hade något större problem med att använda biblioteket.

20 4 Implementation

4.2.4

Ping

Sedan kommer klienten att pinga Exchange Servern. Klienten meddelar vilka mappar som är aktuella ifall någon förändring har skett. När en viss tid har gått, som klienten har skickat med i förfrågningen, förväntar klienten ett svar från Exchange Servern även om ingen förändring i någon mapp har skett.

Sker en förändring i någon mapp som är aktuell för klienten kommer Exchange Servern returnera de aktuella mapp id. Klienten kommer därefter begära att syn- kronisera innehållet i den mapp som förändring skedde i. Sedan återgår klienten till att begära att få lyssna på förändringar i mappar.

4.2.5

Övriga kommandon

Om en kalender har lagts till, tagits bort eller bytt namn på klienten kommer klienten att meddela Exchange Servern om detta. Det finns även ett kommando som meddelar att en kalenderhändelse har flyttats från en kalender till en annan.

5

Diskussion

Implementationen skulle kunna ha testats mer grundligt med flera olika klienter. Det utfördes inte på grund av brist på tid samt tillgång på olika klienter. De flesta problem, och mest tid, har lagts ner innan på att förstå samt lägga upp grunden för implementation av Exchange ActiveSync-protokollet.

Det finns fortfarande möjligheter att implementera större delar av Exchange ActiveSync- protokollet men även CloudTop skulle kunna anpassas för bättre stöd för Ex- change ActiveSync.

5.1

Testning

Vid testning av implementationen användes Android SDK samt en iPhone och en iPad. Testning utfördes genom att utföra olika moment till exempel lägga till, ta bort samt ändra en kalenderhändelse på både klient och på kalenderapplika- tionen i CloudTop.

Implementationen skulle kunna testas med ännu flera olika klienter, dock var aldrig aktuellt att testa på fler än de nödvändiga på grund av den extra tid det skulle ta. Android SDK användes vid testning då jag inte hade tillgång till någon tillräckligt ny Android-klient.

Det är först i Android 4.0 eller senare som det finns ordentligt stöd för Exchange ActiveSync. Tidigare versioner av Android har endast stöd för äldre versioner av protokollet.

22 5 Diskussion

5.2

Problem

Ett stort problem i början var att hitta utvecklingsverktyg och sätta upp utveck- lingsmiljön och testmiljön. Det fanns väldigt lite information att tillgå, både på internet eller på Xcerion, vad som skulle användas för att implementera en Ex- change Server. Det är, enligt min uppfattning, en väldigt ovanlig implementation. Det vanligaste är att företag köper en licens för en Microsoft Exchange Server eller använder någon öppen källkodslösning med stöd för Exchange ActiveSync- protokollet.

Det tillgängliga öppen källkodslösningarna var inte heller till mycket hjälp då min implementation skiljer sig avsevärt ifrån deras. Implementationen är ett API som ska kommunicera med en klient och sedan direkt med Xcerion Baxide-WS. Någon sådan implementation eller något liknande existerar inte redan, utan det var uppgiften i mitt examensarbete att skapa en sådan Exchange Server.

Ett annat problem var att dokumentationen Microsoft tillhandahåller är riktat till hur det är tänkt att en klientutvecklare ska implementera Exchange ActiveSync- protokollet. Det var ganska irriterande i början men man vande sig snabbt att vända på meningarna. Till exempel om det står att en klient förväntar sig en viss data så bör man anta att Exchange Servern ska ha skickat datan.

Det var också mycket nytt som jag behövde sätta mig in i till exempel WBXML. Dessutom fungerade inte biblioteket från början till Ubuntu. Eftersom Exchange Servern i slutändan skulle köras i Ubuntu-miljö, och därför jag inte hitta något bättre bibliotek, blev jag tvungen att själv fixa så att biblioteket (libWBXML) fun- gerade till Ubuntu då jag behövde komma framåt i examensarbetet.

Att rätta till libWBXML-modulen, tillsammans med att integrera avkodaren samt kodaren av WBXML till Exchange Servern, var den mest tidskrävande delen av examensarbetet.

Själva Exchange ActiveSync-protokollet har varit den lättare biten. Det svåra med implementationen har varit alla detaljer som protokollet innebär till exempel alternativa implementationer och omfattningen av olika element.

Ett annat problem är, om en klient får ogiltig data från Exchange Servern, så presenteras som regel inget fel. Man märker att det har blivit fel genom att inget händer, det är inte heller meningen att klienten ska meddela Exchange Server om att någonting på klienten har blivit fel. Då är det bra att kunna kommunicera med till exempel en Microsoft Exchange Server, som förmodligen har en korrekt implementation redan, och avlyssna den datan för att sedan jämföra med datan där det har blivit fel.