Abstrakt. Nyckelord: XML, Web service, Outlook, MySQL, Import, Export, COM

Transkript

1 Abstrakt StudentSMS saknar i dagsläget möjligheten att importera och exportera kontakt- och kalenderuppgifter mellan Microsoft Outlook och StudentSMS egen databas av märket och typen MySQL. Målsättningen för detta arbete är att finna och ta fram en sådan lösning. Den framtagna lösningen består på serversidan av en web service skriven i Java och en MySQL-server, samt en klientprogramvara som är utvecklad i C#. Denna programvara ansluter till Outlook och hämtar ut det efterfrågade data och synkroniserar detta med MySQL-databasen med hjälp av en web service. Slutsatsen är därför att det går att importera data från Outlook till StudentSMS och tvärtom. Även en fullständig synkronisering har testats framgångsrikt denna funktion är dock ej ännu fullt implementerad på grund av att detta arbetes mål var att ta fram en lösning för import och export av data. Nyckelord: XML, Web service, Outlook, MySQL, Import, Export, COM i

2 Innehåll 1 Förord 1 2 Inledning Bakgrund Syftet med arbetet Syftet med uppsatsen Metod för arbetet Avgränsningar Disposition Begreppsapparat World wide web consortium XML XPath XLink och XPointer XSLT XQuery Web services SOAP WSDL Tomcat Axis MySQL Secure socket layer Component object model Extrem programmering Unified process Avhandling Lösningsförslag Fördelar respektive nackdelar med de olika alternativen Utvecklingsmiljö Systemering Systemutveckling Systemtest Avslutning Resultat Slutsats Diskussion Problem och lösningar vid utvecklingsarbetet Fortsatt forskning/utökning Referenser 26 ii

3 A Bilagor 28 A.1 Klassdiagram server (stor version) A.2 Klassdiagram klient (stor version) A.3 WSDL Sakregister 31 Figurer 1 Xpath:s uppbyggnad RUP:s faser och arbetsflöden NET-klient Java-klient Use case-diagram Lösningens arkitektur Klientens GUI Klientens aktivitetsfältsikon Serverprogramvarans klassdiagram (förenklad) Klientprogramvarans klassdiagram (förenklad) Serverprogramvarans klassdiagram (stor version) Klientprogramvarans klassdiagram (stor version) iii

4 1 Förord Vi tackar företaget Nostratic för att denna avhandling kan genomföras. Vi tackar även våra handlare Torsten Palm från Uppsala universitet och Mikael Ek från Nostratic. Vi riktar också ett stort tack till Johan Roos för all hjälp med L A TEX. 1

5 2 Inledning 2.1 Bakgrund Nostratic AB grundades år 2004 av Albert Bengtsson och Kristian Enström och har som affärsidé att utveckla och anpassa avancerade communitysystem 1 åt företag, universitet och övriga organisationer. Nostratics visioner är att bli den självklara leverantören av mobila internetcommunitys. Företaget har sitt kontor i Novum Forskningspark, beläget i Huddinge. StudentSMS är en produkt framtagen av Nostratic och är en webbcommunity som är specialdesignad för att passa samtliga lärosäten. Syftet är att lärare och studenter ska kunna kommunicera med varandra via SMS, e-post och instant messaging. 2 StudentSMS saknar i dagsläget möjligheten att importera och exportera kontakt- och kalenderuppgifter mellan Microsoft Outlook och Nostratics egen databas av märket och typen MySQL. 2.2 Syftet med arbetet Syftet med vår avhandling är att hitta den lösning som lämpar sig bäst för StudentSMS vid import och export av kalenderobjekt och kontakter mellan Outlook och Nostratics tjänst StudentSMS och implementera denna lösning. 2.3 Syftet med uppsatsen Uppsatsens syfte är att redovisa vårt utvecklingsarbete, våra resultat samt våra uppkommande problem och dess lösningar. 1 En community är en mötesplats på Internet. 2 ( 2006) 2

6 2.4 Metod för arbetet Vårt angreppssätt på detta problem är att undersöka olika tänkbara lösningar för att importera och exportera data och sedan implementera detta koncept. Möjligheten att synkronisera data är även undersökt och genomförbart med denna lösning men inte implementerad. Eftersom den teknik vi använder är så pass ny har informationen inte hämtats ur böcker inom området. Vi har istället studerat de rön som finns ute på Internet angående de tekniker som har tillämpats. Vi har gått igenom otaliga tutorials och dokumentationer som har varit relevanta för de teorier som har undersökts. Efter att ha tagit del av den informationen har vi kunnat besluta vilka lösningar som är möjliga för vårt fall och till slut valdes den implementerade lösningen. Under själva utvecklingsarbetet har vi inte använt oss av någon renodlad utvecklingsmetod, utan mera en anpassad metod för syftet. Detta är ett relativt litet projekt så att använda UP (Unified process, se avsnitt på sida 9) hela vägen ut verkade inte realistiskt. Vi har mest använt oss av XP (Extrem programmering, se avsnitt på sida 9) med vissa inslag av UP eftersom det finns bra delar från båda som tillsammans passar vårt syfte. 2.5 Avgränsningar Eftersom StudentSMS enbart är intresserade av ett fåtal kalenderattribut så har arbetet begränsats till import och export av dessa attribut, mellan StudentSMS och Outlook. 2.6 Disposition Upplägget på denna avhandling är uppbyggd så att varje fas i utvecklingsprocessen presenteras i en punklista, så att det enkelt ska gå att följa och hitta det avsnitt som läsaren eftersöker. Figurer som presenteras utan källangivelse i rapporten är egna. 3

7 2.7 Begreppsapparat I detta avsnitt tas upp de termer och begrepp som är relevanta och som används inom utvecklingsprocessen av vår synkroniseringsapplikation. Dessa är sorterade i en avtagande hierarki där högsta nivån är först och därefter fördjupas i dess undernivåer World wide web consortium W3C eller World wide web consortium är ett industrikonsortium med över 500 medlemmar från ledande industrier, forsknings- och utvecklingsinstitut, standardiseringsorgan och regeringar samt EU. Tillsammans med statliga bidrag så finansieras deras verksamhet av dess medlemmar. W3C arbetar med utveckling av tekniska protokoll och standarder för webben och har som mål att leda Internet till dess fulla potential genom ett öppet samarbete. De tekniska standarder som W3C har utvecklat är bland annat HTML, CSS, SMIL, XML och SVG XML Conolly 4 et al skriver att XML står för extensible Markup Language. Med extensible menas att användaren kan skapa egna taggar med egna unika egenskaper. XML beskrivs som ett metaprogrammeringsspråk. Med andra ord ett språk för att beskriva andra språk. XML är en begränsad version av SGML (Standard Generalized Markup Language), och är framtaget speciellt för webbdokument. SGML är ett system för att definiera strukturerade dokument och är ett markupspråk för att representera instanser av dessa dokumenttyper. SGML har varit en standard för att underhålla strukturerade dokument mer än ett decennium. SGML gör det möjligt att dela upp dokument i två logiska delar. En del som innehåller strukturen för dokumentet och en annan del för själva innehållet. Strukturdelen kallas för DTD (Document Type Definition). Genom att man separerar strukturen på dokumentet från innehållet kan författaren enkelt förändra strukturen på dokumentet på ett mycket kraftfullt sätt. SGML har dock inte blivit lika vida spritt som XML på grund av sin medkomplexitet. XML försöker att efterlikna SGML s funktionalitet men på ett mindre komplext sätt och på samma gång vara nätverksmedvetet. XML stöds av ett så stort antal olika plattformar så att det anses vara plattformsoberoende. XML bibehåller de bästa egenskaperna hos SGML, såsom struktur, validering och modifierbarhet. Det gör att SGML-system kan läsa XML dokument. Ett XML-system däremot kan inte läsa SGML-filer. 3 ( 2006) 4 (Connolly and Begg, 2005) 4

8 2.7.3 XPath XPath är ett sökspråk designat för att hämta information ur ett XML-dokument, språket används för att navigera mellan element och attribut i dokumenten. XSLT (se avsnitt 2.7.5), XQuery (se avsnitt 2.7.6), XLink och XPointer (se avsnitt 2.7.4) bygger till stor del på XPath (se figur 1 5 för bild på hur Xpath är uppbyggd). En god förståelse av XPath är därför nödvändig vid mer avancerad användning av XML XLink och XPointer Det finns två olika metoder för länkning inom XML, nämligen XLink och XPointer. XLink definierar en standard för hur hyperlänkar inom XML-dokument ska skapas, medan Xpointer tillåter dessa hyperlänkar att peka på specifika fragment inom XML-dokumentet XSLT XSL står för Extensible stylesheet language och är skapat av W3C därför att det fanns ett behov för ett stilmallsbaserat språk ( style sheets ) för formatering av XML-dokument. XSLT står i sin tur för XSL tranformations XQuery Det enklaste sättet att beskriva XQuery är att säga att XQuery är för XML som SQL är för relationsdatabaser, alltså ett frågespråk designat för uthämtning och beräkning av data inom XML-dokument 9. 5 ( 2006) 6 ( 2006) 7 ( 2006) 8 ( 2006) 9 ( 2006) 5

9 Figur 1: Xpath:s uppbyggnad Web services Web services competence center 10 beskriver Web Services som en standard som tillåter informationssystem att utbyta information, samverka och använda varandras information på ett enhetligt sätt. Web Services är i grunden uppbyggt av XML med ett antal påbyggnadsstandarder såsom SOAP, WSDL och så vidare. Den väsentliga skillnaden mellan Web Services och andra liknande lösningar är att industrierna mer öppenhjärtigt stöder Web Services. Företagsjättar som IBM, Sun, Microsoft, Oracle och många andra samlas kring denna nya standard. Formellt definieras Web Services av organisationen the World Wide Web Consortium (W3C) SOAP Enligt W3C 11 är SOAP ett protokoll för utbyte av XML-baserade meddelanden över datorbaserade nätverk. Normalt skickas SOAP-meddelanden över HTTP, men den kan också använda sig av andra transportprotokoll WSDL W3C 12 skriver att WSDL är ett XML-format som används för att beskriva olika typer av nätverkstjänster. Operatorer och meddelanden beskrivs abstrakt i dokumentet och kopplas därefter till ett lämpligt nätverksprotokoll (t.ex. SOAP), samt till ett meddelandeformat. 10 ( 2006) 11 ( 2006) 12 ( 2006) 6

10 Tomcat Enligt apache.org 13 är Tomcat den servlet container som används vid implementation av den officiella versionen av Java servlets 14 och Java server pages (JSP) 15. Specifikationerna för Java Servlets och JSP utvecklas av Sun. Tomcat släpps under licensen Apache Software License och är en så kallad open source - programvara Axis2 Enligt wikipedia 16 så är Apache Axis en web service framework skriven i Java. Axis består av en implementation av en SOAP-server och den tillhandahåller även ett antal verktyg och API:er för programmering och användning av web service -applikationer. Axis är så kallad open source - programvara. Förutom en Java-implementation så finns även en C++-implementation av Axis tillgänglig MySQL Wikipedia 17 skriver att MySQL är ett SQL-baserat databashanderingssystem, vars antal beräknade installationer i dagsläget är över sex miljoner. Företaget MySQL AB har släppt MySQL som open source -programvara under licensen GNU general public license (GPL), men den är även licensierad som proprietär programvara för fall där det tänkta användningsområdet inte överensstämmer med GPL-licencen. 13 ( 2006) 14 Java servlets är ett API som tillåter utvecklare att dynamiskt koppla javakod med en web server 15 JSP ger utvecklare av webbsidor möjligheten att blanda vanlig, statisk HTML, med dynamiskt genererat innehåll från servlets 16 ( 2006) 17 ( 2006) 7

11 Secure socket layer Enligt Wikipedia 18 så är SSL en standard för kryptering av webbtrafik. SSL fungerar så att det skapar en kanal mellan två datorer eller till exempel mellan användare och server. När användaren skickar data till servern så krypteras data medan den förblir oförändrad om överföringen sker utan SSL. SSL lägger även till digitala signaturer för att kunna identifiera server och användare. Vid användning av SSL så krävs ett så kallat SSL-certifikat. SSL är det mest utvecklade säkerhethetsprotokollet som finns att tillgå idag och används främst för att säkra internettransaktioner men kan också användas för att stödja samt säkra annan trafik som till exempel filöverföring mellan FTP eller e-postöverföring via SMTP. SSL utvecklades ursprungligen av Netscape. OpenSSL är en fri implementation av SSL Component object model COM står för Component object model och är en teknologi som tillåter kommunikation mellan externa program. COM används av utvecklare för att till exempel skapa återanvändbara programvarukomponenter eller länka olika komponenter mellan varandra vid applikationsbyggnad. Till COM hör teknologier såsom COM+ och Distribuerad COM (DCOM). COM används av applikationer såsom Microsoft Office. Till exempel så tillåter COM worddokument att dynamiskt länka data mellan Word och Excel ( 2006) 19 ( 2006) 8

12 Extrem programmering Enligt Wikipedia 20 är Extrem programmering (XP) en systemutvecklingsmetodik som ursprungligen är skapad av Kent Beck. XP utvecklades på grund av att många systemutvecklingsprojekt avbröts i förtid eller att projektplanen inte kunde hållas. XP är baserat på fyra stycken värderingar, dessa är: Kommunikation Enkelhet Återkoppling Mod Kommunikation står för kommunikationen mellan kund och programmerare. Det är viktigt att ha en kund på plats så att kontinuerlig kommunikation mellan utvecklarna och kunden är möjlig. Kunden som är på plats har möjlighet att bestämma vad som ska uppfyllas av systemet och i vilken ordning dessa ska prioriteras. Enkelhet uppnås genom kontinuerlig omstrukturering av kod, samt att skapa minimalt med beskrivande dokument och annat som inte är en del av det slutgiltiga systemet. Återkoppling uppnås genom kontinuerliga enhetstester och många delleveranser av systemet. Kopplingen mellan kommunikation och återkoppling är särskilt viktig då kunden kan ge fortlöpande feedback på systemet. Mod är med som hörnsten mest som ett skämt, men har en allvarlig underton då det i XP är extra viktigt att alla projektmedlemmar vågar vara helt ärliga med vad de inte kan och kan göra, samt att de har modet att ta på sig uppgifter som inte alltid är populära. XP är den mest populära lättviktsprocessen idag och har bevisats vara effektiv då den har använts i flera projekt runt om i världen Unified process Enligt Larman 21 är Unified process (UP) är en systemutvecklingsmodell för design och implementering av IT-system. UP skapades av företaget IBM Rational software, som även har sin egen tolkning på UP (även kallad RUP). 20 ( 2006) 21 (Larman, 2005) 9

13 RUP grundar sig på användandet av en iterativ utvecklingscykel. Tanken är att RUP ska kunna skräddarsys så att den passar in i enskilda organisationer och projekt oberoende tidigare policys och företagskultur. RUP delas in i fyra faser som ett projekt går igenom efter hand. Varje fas avslutas med en väldefinierad milstolpe där specifika delmål måste ha uppfyllts. Dessa fyra faser är: Förberedelse (Inception) Etablering (Elaboration) Konstruktion (Construction) Överlämning (Transition) Varje fas består av en eller flera iterationer (se figur 2 22 för exempel på RUP:s faser och arbetsflöden). Antalet iterationer och dess längd beror på projektets storlek, ett stort projekt behöver ofta fler och längre iterationer. Figur 2: RUP:s faser och arbetsflöden Iterativ systemutveckling är till skillnad från vattenfallsmodellen bevisad att den kan lösa många problem som kan tänkas uppstå i mjukvaruprojekt. I en iterativ utvecklingsmodell är det möjligt att gå tillbaka och till exempel ändra på kravspecifikationen för systemet och planera om de efterföljande iterationerna. 22 (Larman, 2005) 10

14 3 Avhandling De olika stegen i utvecklingsprocessen: Ta fram en hållbar och robust lösning som fungerar mot den plattform som företaget använder, med samråd och godkännande av företaget (Lösningsförslag, se avsnitt 3.1). Sätta upp en utvecklingsmiljö från grunden med bland annat konfiguration av servrar installation av Tomcat och Axis2 och så vidare (Utvecklingsmiljö, se avsnitt 3.2). Systemera programmet baserat på den lösning som presenterats (Systemering, se avsnitt 3.3). Utveckla programvaran (Systemutveckling, se avsnitt 3.4). 3.1 Lösningsförslag Efter första kontakten med Nostratic, kom vi fram till, att för enkelhets skull, vara på plats redan första veckan, så att vi snabbt skulle kunna komma fram till en lösning. Kommunikationen går så mycket fortare om inte en telefonlur behöver lyftas eller ett behöver skickas i väg så fort en fråga måste besvaras. På detta sätt sker jobbet nära kunden. En närmare kontakt med kunden minskar därför sannolikheten att utvecklare och kund har två helt olika idéer och om lösningen. Efter att ha studerat olika metoder, vägt fördelar mot nackdelar, återstod två förslag som presenterades för Nostratic (se figur 4 och figur 3). Den största anledningen varför vi kom fram till dessa är att eftersom Outlook har ett slutet API och denna specifikation kostar att få tillgång till, används istället en.net-lösning på klientsidan. I en.net lösning finns ett API (Component object model,se avsnitt ) tillgängligt, för kommunikation mellan externa programvaror, vilket möjliggör vår lösning. Det finns även programvaror som möjliggör programmering mot Component object model i javamiljö, men många av dessa har så pass höga licenskostnader att de aldrig sågs som alternativ av Nostratic ( 2006) 24 ( 2006) 25 ( 2006) 11

15 1. Skapa en helt egen.net connector mot Outlook. (se figur 3) 2. En java-connector mot Outlook finns tillgänglig, den har dock en licenskostnad på 1 900:- per utvecklarlicens. 26 (se figur 4) Figur 3:.NET-klient Figur 4: Java-klient Fördelar respektive nackdelar med de olika alternativen Fördelar med.net Genom att vi själva skapar ett program från grunden så får vi kontroll över alla funktioner. Användaren kan genom ett program alltid synkronisera, med andra ord behöver han/hon inte starta upp en webbläsare. Nackdelar med.net Användaren måste hämta hem en programvara från Internet och installera denna (engångsföreteelse). Dålig säkerhet utan kryptering (men det går att kryptera XML-dokumentet i SOAP med minst 128bitars-kryptering, läs mer under säkerhet). Ej plattformsoberoende. Användaren måste ha.net-framework installerat (brukar följa med XP) 26 ( 2006) 12

16 Fördelar med Java Användaren behöver inte hämta hem och installera någon applikation på sin dator om lösningen är applet-baserad. Nackdelar med Java Användaren måste varje gång logga in samt gå in på en specifik sida för att använda tjänsten som synkroniserar. Det redan utvecklade API:et för kontakt mot Outlook kostar 1900:- (Per utvecklare). Eftersom vi köper ett bibliotek som kopplar upp sig mot Outlook så blir vi hänvisade till detta, om de till exempel funderar på att ta ut mer licenskostnader. Användaren måste förmodligen hämta hem JRE (Java runtime enviroment), eftersom den inte finns med i grundinstallationen. Säkerhet Eftersom den information som ska skickas över Internet med denna programvara är av känslig karaktär (personliga kontakter och kalenderinformation), krävs god säkerhet vid dataöverföringen. Hantera säkerhet vid överföring med JSP (alternativ 1) 1. Genom att tunnla och kryptera data med SSL (128-bitars kryptering). 2. Det finns även en möjlighet att via JSSE ( Java secure socket extensison) kombinera RSA och en SSL tunnling det vill säga bitars kryptering. Alla banköverföringar och till exempel transaktioner med VISA nöjer sig med 128-bitars SSL-kryptering. Hantera säkerhet vid överföring med SOAP (alternativ 2) Genom att tunnla och kryptera SOAP-data med SSL (128-bitars kryptering. Genom kryptering av XMLdokumentet (upp till 2048-bitars kryptering). Vår rekomendation Vi förespråkar.net-lösning eftersom den kan skräddarsys helt oberoende av externa parter och är framförallt helt gratis. Detta blev också Nostratics val. 13

17 3.2 Utvecklingsmiljö Införskaffande av hårdvara Eftersom det inte fanns någon tillgänglig server som kunde användas i den utvecklingsmiljö som krävdes, så införskaffades en serverdator. På detta sätt har uppnåddes fullständiga rättigheter både på server och klientsidan. Val av programvara, till servern Som operativsystem på servern valdes Ubuntu Linux eftersom det är gratis och Linux/Unix är den serverplattform som Nostratic använder som plattform. Tillägsprogramvaror som har installerats är MySQL, Java JDK 1.5,OpenSSL, Apache Tomcat med tilläggspaket såsom Axis2 och Xerces. Val av programvara, till klienten Operativsystemet på klienten är windows Detta val grundar sig på att den inköpta laboreringsdatorn är av en äldre modell. Som klientprogramvara är Microsoft Office 2003 installerat med tillhörande Microsoft Outlook Utvecklingsprogramvaror är Microsoft Visual Studio av version 2005 och.net v2.0 SDK. Anledningen till att utvecklingen sker i C# och mot.net-api:t är därför att stödet för programmering mot externa Microsoft-programvaror (via COM) är betydligt större i.net jämfört med Java. 14

18 3.3 Systemering För att skapa ett system som svarar mot de efterfrågade behoven inleddes en systemeringsfas. Arbetet med systemeringen började med en undersökning av redan gjorda synkroniseringslösningar, såsom Palm:s Tungsten och Sony Ericsson:s programvara för synkronisering mellan sina smartphones(till exempel P800/900/910) och Microsoft Outlook. Det som undersöktes var bland annat hur synkroniseringslösningen såg ut samt hur GUI-lösningarna var uppbyggda. Nästa steg i systemeringsprocessen var att ta fram och modellera användningsfall(use case, se figur 5), samt rita klassdiagram för både klient (se figur 9) och server (se figur 10). För att uppnå en tillfredsställande objektorienterad lösning så togs beslutet att tillämpa trelagersarkitektur på både serversidan och klientsidan. Trelagersarkitektur går ut på att separera objekten i tre lager. Nämligen i ett presentationslager, ett kontrollager och ett databaslager, detta för att göra programkoden mera skalbar och modifierbar. Till alla lager finns även ett antal så kallade entitetsklasser 27 kopplade. En entitetsklass är en hjälpklass som skapas med syftet att förenkla kommunikationen mellan en objektorienterad systemarkitektur och relationsbaserade databaser. Generellt kan man säga att en entitetsklass är en objektorienterad representation av en tabell i databasen, där varje kolumn i databastabellen representeras av ett attribut i denna klass. Figur 5: Use case-diagram 27 (Larman, 2005) 15

19 3.4 Systemutveckling Vår systemutveckling innehåller följande delar:.net-klient med aktivitetsfältsikon Web service WSDL Java-gränssnitt som vidarebefodrar data från web service vidare till affärslogiken 28 Java-affärslogik som skickar och hämtar information från MySQL-databasen Figur 6: Lösningens arkitektur.net-klient med aktivitetsfältsikon Som tidigare tagits upp så fattades beslutet att använda C# och Microsoft Visual Studio som utvecklingsplattform på grund av att.net genom COM har ett fullt tillfredsställande API för programmering mot Outlook. GUI:ets utseende är skapat med åtanken att användaren så enkelt som möjligt, utan tidigare kunskap om programvaran, ska kunna genomföra en synkronisering (se figur 7). Det beslutades också att skapa en aktivitetsfältsikon (se figur 8) för att programmet snabbt och enkelt ska kunna gömmas undan när det inte används men ändå vara lättåtkomligt för användaren. Klienten är uppbyggd på trelagerarkitektur med ett presentationslager (alltså GUI:et), ett kontrollager och ett databaslager (med två klasser; en klass sköter all kommunikation med Outlook och den andra sköter all kommunikation med web service ) När användaren har fyllt i alla användaruppgifter och han/hon klickar på knappen Synkronisera, körs en metod i kontrollagret som anropar databaslagrets klass för kommunikation mot Outlook. 28 Affärslogik är kärnan i applikationen. Det är genom affärslogiken allt informationsflöde sker. 16

20 Figur 7: Klientens GUI Figur 8: Klientens aktivitetsfältsikon Denna klass hämtar ut data från Outlook som den sparar ner i en DataSet som skickas tillbaka till kontrollagret. Väl tillbaka i kontrollagret konverteras detta DataSet till ett XML-dokument och en metod som tar kontakt med databaslagrets klass för kommunikation mot web service anropas.när denna metod körs så skickas XML-dokumentet till servern som synkroniserar data mot sin egen som är sparad i en MySQL-databas. Servern skickar därefter tillbaka ett XMLdokument med data som antingen ska uppdateras eller skapas i Outlook till klienten. Klienten tar emot XML-dokumentet som i kontrollagret traverseras igenom och skapar en lista av entitetsobjekt. Listan skickas därefter vidare till databaslagret som går igenom listan entitet för entitet och sparar/uppdaterar data i Outlook. 17

21 WSDL (web service) Det finns två angreppssätt vid utveckling av WSDL. Antingen kan utvecklarna välja att generera stubbkod 29 (till både serversidan och klientsidan) från ett redan skrivet WSDL-dokument eller att generera ett WSDL-dokument från en färdigskriven serverkod. Vi valde att skriva ett servergränssnitt och generera ett WSDL-dokument utifrån detta. Detta WSDL-dokument användes därefter för att automatiskt generera källkoden för anslutning till web service åt klienten. (Se bilaga A.3). Java-gränssnitt som vidarebefodrar data från web service till affärslogiken Detta gränssnitt är presentationslagret på serversidan. Det är uppbyggt i form av ett gränssnitt som tar emot XML-dokument och för vidare den data som det erhåller till kontrollagret. Efter genomförd synkronisering tar det emot ett av affärslogiken genererat XML-dokument som det skickar tillbaka till den anslutande klienten. Javabaserad affärslogik som skickar och hämtar information till/från en MySQL-databas Affärslogiken är också den uppbyggd på klassisk trelagersarkitektur. Det innebär att det finns ett: DAO(Database Acess Objekt)-lager Kontrollager Presentationslager. Detta ökar säkerheten och skalbarheten, så att ett lager enkelt ska kunna bytas ut eller ändras. Kontrollagret sköter all kommunikation med presentationslagret och databaslagret. Det är också kontrollagret som sköter själva synkroniseringen. Databaslagret sköter all kommunikation till och från databasen. Vid anslutning mot web service så skickas det mottagna XML-dokumentet vidare till kontrollagret. XML-dokumentet traverseras därefter igenom och skapar ett antal listor med entitetsobjekt. Dessa listor synkroniseras sedan med ett antal listor som hämtas från databasen via databaslagret. Vid synkroniseringen skapas två nya listor, en version som sparas/uppdateras på servern och en annan som skickas tillbaka till klienten för att sparas/uppdateras i Outlook. Den lista som skickas tillbaka till klienten konverteras till ett XML-dokument och skickas därefter tillbaka. 29 Stubbkod är skapade, men ej implementerade metoder 18

22 3.5 Systemtest Under systemtestningen ingick följande moment: Test med extremvärden Prestandatester, det vill säga att undersöka tidsåtgången för synkronisering vid olika situationer. Klientprogramvaran är testad mot en dator med programvarukonfigurationen: Windows 2000 SP4 Outlook 2003 Microsoft.NET Framework v2.0 Serverprogramvaran är testad mot en dator med programvarukonfigurationen: Ubuntu Linux 5.10 MySQL Java Apache Tomcat Apache Axis

23 4 Avslutning 4.1 Resultat Nostratic valde den av oss rekommenderade lösningen, det vill säga alternativet med en.netklient. (se figur 3 på sida 12) På klientsidan:.net C# På serversidan: Java. Säkerhet: SSL(OpenSSL) Vi har även modellerat två stycken UML-klassdiagram för att enklare kunna visualisera hur den framtagna lösningen kommunicerar mellan klasserna. Det första klassdiagrammet visualiserar serverlösningen (se figur 9), medan det andra visualiserar klientlösningen (se figur 10) Figur 9: Serverprogramvarans klassdiagram (förenklad) 20

24 Figur 10: Klientprogramvarans klassdiagram (förenklad) 4.2 Slutsats I denna avhandling har vi undersökt tänkbara lösningar att synkronisera data från Outlook och StudentSMS. Den slutsats som kan dras är att den metod som vi har valt att använda oss av fungerar. Det går att importera data från Outlook till StudentSMS och vice versa. Även synkronisering är möjlig med vår lösning, dock ej ännu fullt implementerad. Vi har med vår lösning lyckat skapa en koppling mellan två så skilda plattformar som en windowsplattform med.net-framework och en linuxplattform med Java. Detta är ett tecken på att web services är framgångsrikt som koncept. Dess huvudsyfte har uppnåtts, det vill säga att tillåta informationssystem utbyta information samt att samverka och använda varandras information på ett enhetligt sätt. 21

25 4.3 Diskussion Eftersom tekniken med web services och de lösningar vi valt att använda är så pass ny, så finns det begränsat med tryckta källor att hämta information ur. Vi har fått tillförlita oss på tutorials och dokumentation som funnits på Internet. När sedan vi fått tag i den information som efterfrågats för att systemutveckling ska kunna bedrivas, så har vi mer eller mindre fått använda trial and error som metod. Vi har gått igenom ett stort antal tutorials. Inga av dessa har enskilt lett till någon fulländad lösning. Genom att hämta lite här och där från ett flertal olika källor, har vi kommit fram till en adekvat lösning. Detta är ett tecken på att det är komplicerat att implementera samt utveckla via web services. Det märks tydligt att denna teknologi är i startgroparna och är därför ännu inte så användarvänlig. Vi hittade mitt inne i utvecklingsarbetet en Open source -baserad programvara för programmering mot Component object model i javamiljö 30. Trots detta så förespråkar vi fortfarande en lösning med.net-klient med web service. Detta på grund av att en.net-lösning är mer integrerad i operativsystemet och går att skräddarsy mot operativsystemet betydligt mer än i Java och att en lösning med web service är mer modulär och skalbar än en java-appletlösning. Vi hade kunnat beakta andra alternativ än web services mer seriöst (som till exempel COR- BA). Anledningen till att valet föll på web services är framför allt att Nostratic redan innan arbetets början bestämt sig för att börja använda web services på sin serverplattform. Därför blev web services det naturliga valet för StudentSMS. Vi skulle även kunnat lägga ner ännu en vecka på undersökning av andra lösningar, men eftersom vi hittat en lösning som StudentSMS var nöjd med så prioriterades utvecklingsarbetet. 30 ( 2006) 22

26 4.3.1 Problem och lösningar vid utvecklingsarbetet Utvecklingsmiljön Problem: Av någon anledning så går inte remote desktop igång mot den labbdator som valts att användas som server. Lösning: Efter flera dagars tester och ett flertal ominstallationer konstaterades ett hårdvarufel. Eftersom remote desktop inte fungerar och att filer som hämtas från Internet är korrupta så dras slutsatsen att felaktigheten sitter i nätverkskortet. Problem: Att installera web service -stöd (Axis) var en aning komplicerat. Det finns mängder med tutorials men ingen verkar överensstämma med vårt ändamål. Med tanke på att det är så många separata moment som krävs för att få den att fungera är nog inte användarvänlighet det första leverantörerna av denna programvara tänker på. Lösning: Genom att byta till den nyare versionen av Axis, Axis2 (beta 0,95), gick installationen och hanteringen mycket smidigare. Klienten Problem: Aktivitetsikonen fungerade inte som den skulle enligt den tutorial som vi gått igenom. Förmodligen beror det på att det är äldre version av Visual studio som den var skriven för. Lösning: Fann en tutorial som var skriven för den nyare versionen av Visual studio. 23

27 Web service/synkronisering Problem: Vi hade problem när vi skulle generera stubbkod från ett WSDL-dokument. Trots att vi testat flera olika metoder så fungerade inte detta angreppssätt. Lösning: vi valde tillslut det andra alternativet, nämligen att skapa ett WSDL-dokument från en färdigskriven stubbkod, eftersom det föreföll vara ett smidigare utvecklingssätt än det föregående. Problem: WSDL-dokumentet var felaktigt, och trots ett otal ändringar så kvarstod problemet. Lösning: Felet var att vi hade fixat en genväg från den jar-fil som skapas i Netbeans till den mapp som den behöver ligga i för att köra WSDL-tjänsten. Efter att kopierat över filen, istället för att enbart länka den, så fungerade allt. Affärslogiken på servern Problem: Vi fick ett underligt felmeddelande i.net-klienten som skriver ut ett Java SQL-execption. Lösning: Detta berodde på att exception-hanteringen i affärslogiken inte var aktiverad, som därför skickade alla uppstående exceptions vidare till klienten. Databasen Problem: Entiteter som redan finns i databasen har ingen creationtime 31, på så sätt kan konflikt uppstå vid synkronisering. Lösning: Genom att en kontroll sker vid synkroniseringen även på startdate 32 och enddate 33 så kommer inte det att ske några konflikter. 31 Ett attribut som innehåller den tid då objektet skapades 32 Startdatum för en kalenderaktivitet 33 Slutdatum för en kalenderaktivitet 24

28 4.3.2 Fortsatt forskning/utökning Programmet behöver inte vara bundet till Outlook utan kan utökas till att passa till exempel Evolution och liknade programvara. Olika klientapplikationer kan använda samma språk (XML), för att skicka data till web service. 25

29 Referenser Connolly, T. and Begg, C. (2005). Database systems. Addison Wesley. Larman, C. (2005). Applying UML and Patterns. Prentice Hall PTR. (2006) :25:33. (2006) :31:06. (2006) :25:12. (2006) :15:30. (2006) :18:21. (2006) :55:33. (2006) :30:43. (2006) :25:54. (2006) :27:31. (2006) :15:30. (2006) :00:12. (2006) :00:12. (2006) :15:30. (2006) :00:02. (2006) :36:55. 26

30 (2006) :09:02. (2006) :00:00. (2006) :00:00. (2006) :00:00. (2006) :00:00. 27

31 A Bilagor A.1 Klassdiagram server (stor version) Figur 11: Serverprogramvarans klassdiagram (stor version) 28

32 A.2 Klassdiagram klient (stor version) Figur 12: Klientprogramvarans klassdiagram (stor version) 29

33 A.3 WSDL <wsdl : d e f i n i t i o n s xmlns : ns1 = h t t p : / / org. apache. a x i s 2 / xsd xmlns : xs = h t t p : / / www. w3. org / / XMLSchema xmlns : soap = h t t p : / / schemas. xmlsoap. org / wsdl / soap / xmlns : wsdl = h t t p : / / schemas. xmlsoap. org / wsdl / xmlns : t n s = h t t p : / / org. apache. a x i s 2 / t a r g e t N a m e s p a c e = h t t p : / / org. apache. a x i s 2 / > <wsdl : types> <xs : schema xmlns : xs = h t t p : / / www. w3. org / / XMLSchema xmlns : ns1 = h t t p : / / org. apache. a x i s 2 / xsd t a r g e t N a m e s p a c e = h t t p : / / org. apache. a x i s 2 / xsd e l e m e n t F o r m D e f a u l t = u n q u a l i f i e d a t t r i b u t e F o r m D e f a u l t = u n q u a l i f i e d > <xs : element name= syncoutlookdatarequest > <xs : complextype> <xs : sequence> <xs : e l e m e n t t y p e = xs : s t r i n g name= xmlelement /> <xs : e l e m e n t t y p e = xs : i n t name= username /> <xs : e l e m e n t t y p e = xs : s t r i n g name= password /> </xs : sequence> </xs : complextype> </xs : element> <xs : element name= syncoutlookdataresponse > <xs : complextype> <xs : sequence> <xs : e l e m e n t t y p e = xs : s t r i n g name= r e t u r n /> </xs : sequence> </xs : complextype> </xs : element> <xs : e l e m e n t name= t e s t S e r v i c e R e q u e s t > <xs : complextype /> </xs : element> <xs : element name= t e s t S e r v i c e R e s p o n s e > <xs : complextype> <xs : sequence> <xs : e l e m e n t t y p e = xs : s t r i n g name= r e t u r n /> </xs : sequence> </xs : complextype> </xs : element> </xs : schema> </wsdl : types> <wsdl : message name= syncoutlookdatarequestmessage > <wsdl : p a r t name= p a r t 1 e l e m e n t = ns1 : s y n c O u t l o o k D a t a R e q u e s t /> </wsdl : message> <wsdl : message name= syncoutlookdataresponsemessage > <wsdl : p a r t name= part1 element = ns1 : syncoutlookdataresponse /> </wsdl : message> <wsdl : message name= t e s t S e r v i c e R e q u e s t M e s s a g e > <wsdl : p a r t name= p a r t 1 e l e m e n t = ns1 : t e s t S e r v i c e R e q u e s t /> </wsdl : message> <wsdl : message name= t e s t S e r v i c e R e s p o n s e M e s s a g e > <wsdl : p a r t name= p a r t 1 e l e m e n t = ns1 : t e s t S e r v i c e R e s p o n s e /> </wsdl : message> <wsdl : porttype name= O u t l o o k S e r v i c e P o r t > <wsdl : o p e r a t i o n name= syncoutlookdata > <wsdl : input message= tns : syncoutlookdatarequestmessage /> <wsdl : output message= tns : syncoutlookdataresponsemessage /> </wsdl : o p e r a t i o n> <wsdl : o p e r a t i o n name= t e s t S e r v i c e > <wsdl : input message= tns : testservicerequestmessage /> <wsdl : output message= tns : testserviceresponsemessage /> </wsdl : o p e r a t i o n> </wsdl : porttype> <wsdl : binding name= OutlookServiceBinding type = tns : OutlookServicePort > <soap : b i n d i n g t r a n s p o r t = h t t p : / / schemas. xmlsoap. org / soap / h t t p s t y l e = document /> <wsdl : o p e r a t i o n name= t e s t S e r v i c e ><soap : o p e r a t i o n s o a p A c t i o n = t e s t S e r v i c e s t y l e = document /> <wsdl : i n p u t> <soap : body use = l i t e r a l namespace = h t t p : / / www. org. apache. a x i s 2 /> </wsdl : i n p u t> <wsdl : output> <soap : body use = l i t e r a l namespace = h t t p : / / www. org. apache. a x i s 2 /> </wsdl : output> </wsdl : o p e r a t i o n> <wsdl : o p e r a t i o n name= syncoutlookdata > <soap : operation soapaction = syncoutlookdata s t y l e = document /> <wsdl : i n p u t> <soap : body use = l i t e r a l namespace = h t t p : / / www. org. apache. a x i s 2 /> </wsdl : i n p u t> <wsdl : output> <soap : body use = l i t e r a l namespace = h t t p : / / www. org. apache. a x i s 2 /> </wsdl : output> </wsdl : o p e r a t i o n> </wsdl : binding> <wsdl : s e r v i c e name= O u t l o o k S e r v i c e > <wsdl : port name= OutlookServicePortType0 binding = tns : OutlookServiceBinding > <soap : a d d r e s s l o c a t i o n = h t t p : / / e r s k e n. mine. nu : / a x i s 2 / s e r v i c e s / O u t l o o k S e r v i c e /> </wsdl : p ort> </wsdl : s e r v i c e> </wsdl : d e f i n i t i o n s> 30

34 Sakregister Apache Axis, 23 Axis2, 7, 11, 14, 19, 23 Tomcat, 7, 11, 14, 19 Xerces, 14 Application Programming Interface (API), 11, 13, 14, 16 Component object model (COM), 8, 11, 14, 16, 21, 22 COM+, 8 DCOM, 8 Evolution, 25 Extrem programmering (XP), 3, 9 Återkoppling, 9 Enkelhet, 9 Kommunikation, 9 Mod, 9 Graphical user interface (GUI), 15, 16 Import/Export, 3, 21 Java, 11, 13, 14, Applet, 12, 13 Connector, 12 Development kit (JDK), 14 Gränssnitt, 16, 18 Runtime enviroment (JRE), 12, 13 Secure socket extension (JSSE), 13 Server pages (JSP), 7, 12 Servlets, 7 Klient, 14 17, 20, Kryptering, bitar, 12, bitar, 13 Linux Ubuntu, 14, 19 Microsoft.NET, 11 14, 16, 19 22, 24 C#, 14, 16, 20 Connector, 12 Source Development Kit (SDK), 14 Office, 14 Outlook, 2, 3, 11 19, 21, 25 Visual Studio, 14, 16, 23 Windows 2000, 14, 19 MySQL, 2, 7, 12, 14, 16, 17, 19 Nostratic, 1, 2, 11, 13, 14, 20 StudentSMS, 2, 3, 15, 21 Open source, 7, 22 Apache software license, 7 Gnu general public licence (GPL), 7 Palm Tungsten, 15 Secure socket layer (SSL), 8, 20 OpenSSL, 8, 14 Server, 14, 15, 17, 20, 23 Sony Ericsson P800/900/910, 15 Synkronisering, 3, 4, 12, 15 18, 21, 24 Trelagersarkitektur, 15, 16, 18 Affärslogik, 16, 18 Databaslager, Entitetsklasser, 15, 17, 18 Kontrollager, Presentationslager, 15, 16, 18 UML, 20 Klassdiagram, 15, 20 Use case, 15 Unified process (UP), 3, 9 Construction, 10 Elaboration, 10 Inception, 10 RUP, 10 Transition, 10 Web service, 6, 12, 16 18, SOAP, 6, 12 WSDL, 6, 16, 18, 24 World wide web consortium (W3C), 4 31

35 XML, 4, 12, 17, 18, 25 XLink, 5 XPath, 5 XPointer, 5 XQuery, 5 XSLT, 5 32