UDVIKLING AF ET SOA-BASERET SYSTEM. Morten Feldthaus. Kongens Lyngby IMM-B.Eng-2008-43

UDVIKLING AF ET SOA-BASERET SYSTEM Morten Feldthaus Kongens Lyngby IMM-B.Eng-2008-43

Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 reception@imm.dtu.dk www.imm.dtu.dk IMM-B.Eng-2008-43

Summary Panther Applications has developed a product to internet providers, which manages their customers, network equipment, and more. To relieve supporters and increase customer support, it is desired to facilitate a self service portal where internet users can log in, perform simple operations like ordering products, review orders, etc. This self service portal is to be developed by the internet providers themselves, but they shall have data made available to them by Panther Applications through web services. In this project, an analysis of the technologies and system's requirements has been performed. With this in mind, prototypes have been designed and implemented for a self services portal and for the service provider.

Resumé Panther Applications har udviklet et produkt, der håndterer internetudbyderes kunder, netværksudstyr mm. For at aflaste supportere og forøge kundeservicen, ønskes det at muliggøre en selvbetjeningsportal, hvor internetkunderne kan logge ind, og udføre simple operationer, såsom at bestille produkter, se ordrer mm. Denne selvbetjeningsportal skal udvikles af internetudbyderne selv, men de skal have data stillet til rådighed af Panther Applications vha. web services. I dette projekt er der foretaget en analyse af de teknologier, samt af de krav der er stillet til systemet. På baggrund af dette, er der designet og implementeret prototyper for en selvbetjeningsportal, samt for serviceudbyderen.

Indholdsfortegnelse Summary 3 Resumé 1 Indholdsfortegnelse 2 1 Indledning 1 1.1 Om firmaet, Panther Applications 1 1.2 Motivation 2 1.3 Vision 3 1.4 Problemformulering 4 1.5 Udviklingsproces 5 1.5.1 Tidsplan 5 1.6 Rapportoversigt 6 2 Analyse 7 2.1 Webservices 7 2.1.1 SOAP 8 2.1.2 WSDL 8 2.2 SOA 9 2.2.1 SOA Principper 9 2.2.2 WS-* 10 2.2.3 Sikkerhed 11 2.2.4 Code first/contract first 13 2.3 Servicens indhold 14 2.3.1 Use case 15 2.4 Krav 16 Krav A. Cross-platform kompatibilitet 16 Krav B. Let at bruge 17 Krav C. Metoder 17 2.5 Domænemodel 17 2.6 Delkonklusion 18 3 Design 19 3.1 Case study 1: Web service understøttelse 19 3.1.1 Formål 19 3.1.2.NET platformen 19 3.1.3 PHP 20 3.1.4 Java 22 3.1.5 Konklusion 22

3.2 Arkitektur 23 3.2.1 Services 23 3.2.2 Samarbejde med Panther Admin 24 3.2.3 Arkitekturoversigt 25 3.2.4 Systemets lag 26 3.2.5 Klasse- og sekvensdiagram 27 3.3 Delkonklusion 31 4 Implementering og test 33 4.1 Case study: Systemopsætning 33 4.1.1 Benyttet software 33 4.1.2 Samarbejde med PAS 34 4.1.3 Sikkerhed 35 4.1.4 Case study konklusion 35 4.2 Panther Service 35 4.2.1 Apache Tomcat 36 4.2.2 Apache Axis2 36 4.2.3 Hibernate 37 4.2.4 Databasestruktur 38 4.2.5 Udviklingsmiljø 38 4.2.6 Afhængigheder 39 4.2.7 Unit Tests 40 4.3 Selvbetjeningsportalen 42 4.3.1 Filoversigt 42 4.3.2 Unit Test 43 4.3.3 Blackbox test 44 4.4 Delkonklusion 47 5 Konklusion 49 6 Appendiks 50 6.1 Ordforklaringer 50 6.2 Kildekode 50

1 Indledning I kapitel 1 beskrives motivationen bag projektet, hvilke visioner der er for projektet og der opstilles en problemformulering. Der er desuden en beskrivelse af Panther Applications, firmaet som projektet bliver lavet for. 1.1 Om firmaet, Panther Applications Panther Applications er et mindre firma, der arbejder med softwareudvikling og konsulentydelser. Firmaets produkter er primært henvendt til bredbåndsindustrien, hvor kunderne typisk er bredbåndsleverandører og antenneforeninger. De vigtigste produkter firmaet leverer, er: Data Retention Solution Som følge af et EU direktiv, er der i Danmark vedtaget en lovgivning der kræver, at alle internetudbydere skal logge deres kunders internetaktiviteter. Data Retention Solution er lavet til at opfylde denne lovs krav, og samler den store mængde log-data og præsenterer det i et simpelt interface, der gør det let at samarbejde med myndighederne, når det er nødvendigt. Internet Accounting Solution Denne løsning kan overvåge mængden af data kunder overfører. Dette kan fx bruges fx til forbrugsafregnet bredbånd. Administration Solution Dette produkt hjælper internetudbydere med at holde styr på deres kunder, produkter, netværksudstyr, afregning, overvågning mm. Systemet administreres vha. en webbrowser. Dette projekt beskæftiger sig med Administration Solution. Som nævnt tidligere, er Administration Solution et produkt, der håndterer administrationen af internetudbydernes kunder. Det gælder alt fra afregning til opsætning af switche. Det hele er samlet i et webinterface, hvor supporterer, administratorer osv. kan administrere systemet. Dette webinterface kaldes typisk bare Panther Admin. Et typisk eksempel på brug af Panther Admin ville være en kunde, der ringer til ISP en og vil have opgraderet sin forbindelse. Dette gør supporteren i Panther Admin, som vist på Figur 1-1. Switch konfigurering udføres altså automatisk, når supporteren vælger det nye produkt til brugeren.

1.2 Motivation 2 1 2 3 4 1: En supporter logger ind i Panther Admin, og opgraderer brugerens forbindelse. 2: Panther Admin kontakter en ESG server, og siger at forbindelsen skal være hurtigere. 3: ESG en sender ordren til den switch/dslam brugeren er opkoblet til. 4: Brugerens hastighed er nu hurtigere Internet Figur 1-1 Opgradering af brugerens forbindelse i Panther Admin. 1.2 Motivation Det scenarie, hvor en kunde ringer til ISP ens support og ønsker sin forbindelse opgraderet fungerer fint, men det er dyrt at have supportere, og i en branche hvor alt skal gøres så billigt som muligt, er internetudbyderne meget interesserede i at minimere det nødvendige antal supportere, og i stedet lade kunderne klare opgraderingen selv. Dette gøres vha. et selvbetjeningsinterface. Der er allerede udviklet et selvbetjeningsinterface til Panther Admin, nemlig Panther Self Service se Figur 1-2. Figur 1-2 Panther Self Service 1 Dette selvbetjeningsinterface virker udmærket, men det er bygget op omkring samme struktur som Panther Admin. Det betyder at selvbetjeningsinterfacet er lavet i PHP, og sidernes design er bygget meget statisk op. Det er altså besværligt, og 1 Fra selvbetjeningen på http://mit.dansknet.dk/ (kræver login)

3 Indledning derfor dyrt, at give internetudbyderne frie hænder til at lavet designet på denne side om. Desuden er det umuligt for internetudbyderne at integrere siden med deres eksisterende websites. Dette ønsker Panther Applications at lave om på. Det skal være muligt for internetudbyderne at kunne integrere en selvbetjeningsportal med deres eksisterende systemer. Den nuværende arkitektur kan beskrives som på Figur 1-3. Ansvarsområder: Slutkunde ISP Panther Applications 2 3 1 5 4 1. Slutkunden 2. Selvbetjeningsportal 3. Database 4. ESG 5. Switch/DSLAM som kunden er forbundet til. Internet Figur 1-3 Nuværende model Det er muligt at selvbetjeningsportalen fysisk er placeret på en server hos ISP en, men det er kun Panther Applications udviklere, der har ekspertisen til at vedligeholde og modificere denne. Så derfor ligger portalen i Panther Applications ansvarsområde. Hvis ISP en vil rette noget indhold på siden, vil Panther Applications udviklere skulle tilkaldes. 1.3 Vision Den ønskede model ses på Figur 1-4. Her ligger selvbetjeningsportalen hos ISP en, og er administreret af ISP en selv. Det har ingen betydning for Panther Applications hvilket sprog selvbetjeningsportalen er skrevet i, eller hvor i verden den befinder sig. Så længe den kan forbinde til Panther Applications servicegrænseflade, der er ansvarlig for at stille den funktionalitet til rådighed for selvbetjeningsportalen, som er nødvendig.

1.4 Problemformulering 4 Ansvarsområder: Slutkunde ISP Panther Applications 2 3 4 1 6 5 1. Slutkunden 2. Selvbetjeningsportal 3. Panther Service 4. Database 5. ESG 6. Switch/DSLAM som kunden er forbundet til. Internet Figur 1-4 Ønskede model Ved at benytte denne model vil internetudbyderne selv kunne implementere deres selvbetjeningsportal i deres eksisterende website, hvilket giver deres kunder et langt mere professionelt indtryk. 1.4 Problemformulering Formålet med dette projekt, er at lave en grænseflade der gør det muligt for internetudbydere, at udvikle en selvbetjeningsportal, der udnytter funktionaliteten i Administration Solution. Der foretages en analyse af tilgængelige teknologier, der stiller en sådan grænseflade til rådighed. Der udarbejdes en liste over hvilken funktionalitet der skal være til stede, og hvilke krav der i øvrigt måtte være til denne grænseflade, og ud fra dette opstilles der krav. Der skal udvikles en prototype af en selvbetjeningsportal, der tester funktionaliteten af grænsefladen samt vil fungere som led i dokumentationen, som internetudbyderne får stillet til rådighed. Her er en samlet liste over de fokusområder, denne rapport gennemgår: Undersøges hvilke web service teknologier der er tilgængelige. Opstilles krav til systemet. Laves use cases Opstilles services og metoder. Designes sekvensdiagrammer Opstilles krav om sikkerheden, og udvælge metoder til at overholde denne. Bestemmes hvilke web service teknologier, der skal benyttes i dette projekt. Opstilles domænemodeller. Både for den interne opbygning i web servicen, og den model der udgives.

5 Indledning Lave case studies, der viser hvorvidt teknologien virker i praksis både for web servicen samt klienter. Vælges udviklingsmetoder. Udvikles systemet. Både prototype af web service og klient. Skrive udførlig dokumentation til både web servicen og klienten, så andre kan videreudvikle på systemet, samt udvikle klienter. Laves grundige tests af web servicen samt tests af klienten. Færdiggøres en konklusion. 1.5 Udviklingsproces Projektet håndteres med inspiration fra UP, og vha. Unified Process 4 faser: Inception. Dette er en kort fase, der har et formål at opstille de vigtigste krav til systemet og der kan ses på forslag til arkitekturen. Elaboration. I løbet af elaborationsfasen skal kravene til systemet fastlægges, og der laves en arkitektur der opfylder disse krav. I slutningen af elaborationen ligger arkitekturen fast, og der foreligger en prototype. Construction. Her udvikles systemet, samt dokumentation skrives. Transition. Sæt systemet i produktion. Dette projekt vil ikke fokusere på at sætte systemet i produktion. Der skal naturligvis tages højde for, at systemet skal kunne sættes i produktion. Der udvikles test-driven, med brug af unit tests. 1.5.1 Tidsplan ID Task Name Start Finish okt 2008 nov 2008 sep 2008 dec 2008 jan 2009 11-1 18-1 21-9 5-10 28-9 12-10 2-11 19-10 9-11 7-12 21-12 14-9 26-10 4-1 16-11 23-11 30-11 28-12 14-12 25-1 1 Rapport 01-09-2008 31-01-2009 2 Inception 15-09-2008 03-10-2008 3 Elaboration 09-10-2008 12-11-2008 4 Construction 12-11-2008 31-01-2009 5 Ferie/eksamen 14-12-2008 26-12-2008 6 Udvikling 13-11-2008 14-12-2008 7 8 Test Dokumentation 27-12-2008 05-01-2009 05-01-2009 31-01-2009 Figur 1-5 Tidsplan

1.6 Rapportoversigt 6 1.6 Rapportoversigt Rapporten er bygget op på følgende måde: Kapitel 1: Indledning Giver en introduktion til projektet, gennemgår motivationen for hvorfor projektet skal gennemføres, og beskriver hvad visionen er for projektet.. Kapitel 2: Analyse I analysen beskrives de teknologier, der er involveret i en SOA-arkitektur. Der opstilles en kravspecifikation, og de relevante teknologier udpeges. Der opstilles en domænemodel, og der laves en liste hvilken funktionalitet der skal være i servicen. Kapitel 3: Design I design-fasen udtænkes softwarens arkitektur.. Kapitel 4: Implementering og test I Implementering beskrives det, hvordan softwaren er sammensat. Herunder kodebeskrivelser, softwarekonfiguration osv. Der testes vha. unit-tests og blackboxtests. Kapitel 5: Konklusion Til slut er der en konklusion, der beskriver hvad projektet er kommet frem til, hvordan det har opfyldt forventningerne og om fremtidige planer for projektet.

2 Analyse I dette kapitel beskrives de teknologier, der benyttes til web services, og de relevante teknologier udpeges. Der opstilles krav, og en domænemodel for de data, der skal sendes til og fra internetudbyderen. 2.1 Webservices En web service beskrives som A Web service is a software system designed to support interoperable machine-to-machine interaction over a network 2 En web service er derfor et system, der muliggøre at andre systemer kan kommunikerer med det, uanset de andre systemers interne opbygning, og uden at de andre systemer kender til web servicens interne opbygning. Konkret vil det betyde, at hvis man laver en web service i Java, så vil denne web service kunne tilgås fra alle andre platforme, så længe de understøtter web services. Dvs. man vil kunne lave en klient op mod denne service i C, PHP,.NET eller hvad man nu måtte ønske. Et eksempel på en simpel web service forespørgsel kan ses på Figur 2-1. ServiceRequestor ServiceProvider Request Return Figur 2-1 Typisk web service forespørgsel 2 http://www.w3.org/tr/ws-gloss/

2.1 Webservices 8 2.1.1 SOAP Den mest benyttede protokol til web services er SOAP. I SOAP er beskederne bygget op vha. XML, der gør det let læseligt for mennesker. Det er desuden let at verificere, er veldokumenteret og afprøvet. SOAP benytter ligeledes andre protokoller som transport, typisk HTTP men også fx SMTP. Det er en stor fordel at benytte HTTP, da protokollen er så kendt, og derved allerede er implementeret i alle programmeringssprog og frameworks. Det giver fx mulighed for at benytte tracing værktøjer til debugging, og HTTP slipper desuden gennem stort set alle firewall s, da det jo også bruges til WWW. <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body xmlns:m="http://www.example.org/stock"> <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> SOAP Eksempel, fra http://www.w3schools.com/soap/soap_example.asp Ovenstående er et eksempel på en SOAP forespørgsel. Det er et XML dokument, og enhver der har arbejdet med XML tidligere vil hurtigt kunne forstå hensigten med forespørgslen. På Figur 2-2 er det illustreret hvordan en klient sender en SOAP besked til en web service. Client 1 2 Service 1: SOAP transport, fx HTTP. 2: SOAP message, i XML. Figur 2-2 Web service kald vha. SOAP 2.1.2 WSDL Til at beskrive hvad en web service indeholder, benyttes WSDL, Web Service Definition Language. WSDL er en XML fil, der beskriver hvilke operationer web servicen udbyder, og hvilke datatyper der benyttes til disse operationer. Der kan ligeledes ligge konkrete URL er til hvor denne web service befinder sig. Brugen af WSDL-filer har flere fordele. Når man har en web service, og en WSDLfil der beskriver denne web service, er det muligt at autogenererer klientkode til denne web service vha. værktøjer. Til.NET findes der fx et værktøj, der hedder

9 Analyse wsdl.exe, der laver en proxy klasse. Og til Java findes der fx wsdl2java. Dvs. hvis man har en WSDL-fil, er det muligt på få minutter at lave en simpel klient. I overensstemmelse med WSDL Client Service Figur 2-3 Web service kald med WSDL WSDL kan ligeledes benyttes til validering af SOAP beskederne. Hvis en SOAP besked ikke er i overensstemmelse med WSDL filen, bør web servicen give en fejl. I kraft af, de to systemer, der kommunikerer sammen ikke kender til hinandens interne opbygning, men kun kender til hinandens grænseflader vha. WSDL-filen, er der tale om en løs kobling mellem de to systemer. 2.2 SOA I det foregående afsnit, blev det beskrevet hvad web services er, samt hvordan man kalder web services vha. SOAP og hvordan web services beskrives vha. WSDL. Web services potentiale bliver dog først udnyttet maksimalt, hvis man benytter sig af SOA, Service-Oriented Architecture. SOA er konceptbaseret, og som udgangspunkt ikke henvendt til web services, men web services er meget velegnet til at udnytte SOA s principper. 2.2.1 SOA Principper De vigtigste principper bag SOA, er ifølge Erl 3 : Autonomy, formal contract, loose coupling samt abstraction. Ud over disse fire findes der en række andre principper 4. Autonomy For hver service kræves det, at servicens logik skal ligge indenfor et begrænset område, og at servicen har kontrol over denne logik. Det foretrækkes, at servicen kontrollerer logikken enerådigt, men ofte er dette ikke muligt, da servicens logik kan ligge i et ældre system, der også ligger under andre services område. 3 Service-Oriented Architecture: Concepts, Tehcnology, and Design, s. 292 4 http://en.wikipedia.org/wiki/service-oriented_architecture#principles

2.2 SOA 10 Formal contract En servicekontrakt skal stilles til rådighed for at opstille nogle definitioner for hvordan servicen fungerer mht: Hvilke operationer der tilbydes Hvilke datatyper operationerne benytter sig af Hvor servicen befinder sig Loose coupling Hvis man har to services der kommunikerer med hinanden, så skal det være muligt at ændre hele den ene service grundlæggende uden det ændrer noget for den anden service, hvis blot den ændrede service fortsat overholder den servicekontrakt, der er lavet mellem de to services. Således er de to services svagt koblet. Abstraction Den funktionalitet som en service tilbyder udadtil, skal abstrahere fra logikken, der ligger bag servicen. Det skal altså være muligt at benytte en service, selvom der ikke er kendskab til den underliggende logik. 2.2.2 WS-* Web Services Interoperability Organization (WS-I) er en organisation, der har til formål at opstille retningslinjer for brug af de web service standarder, der allerede findes. WS-I er støttet af alle større SOA udbydere 5. Disse standarder betegnes som WS-* udvidelser, da standarderne typisk har navne, der starter med WS-. WS-I Basic Profile Basic Profile er lavet af WS-I, og opstiller retningslinjer for hvordan, der bedst skabes interoperabilitet ved brug af web services, ved at anbefale bestemte versioner af SOAP, WSDL og UDDI. Ud over Basic Profile er der lavet en lang række web service standarder, der håndterer de fleste af de udfordringer, som en service-orienteret arkitektur står over for. Disse standarder benævnes typisk som WS-* udvidelserne, da de fleste har præfikset WS-. Standarderne ligger typisk under organisationerne W3C og OASIS. Et udpluk af disse WS-* udvidelser beskrives herunder. WS-Addressing WS-Addressing er en udvidelse, der tilføjer informationer til SOAP meddelelser, om hvor besked kommer fra, hvor den skal sendes hen og hvad der skal ske med beskeden, hvis der sker en fejl. WS-ReliableMessaging For at få garanteret levering af beskeder, eller fyldestgørende fejlbeskeder hvis beskeder ikke kan leveres, findes WS-ReliableMessaging. Der understøttes fx 5 Service-Oriented Architecture: Concepts, Tehcnology, and Design, s. 81

11 Analyse sekvenser af beskeder, hvor man sender en række beskeder til en web service, som så svarer tilbage hvilke beskeder der rent faktisk blev modtaget. WS-Policy WS-Policy benyttes til at udvide WSDL, således at der kan opstilles regler for kommunikationen. Policy benyttes til en række af de andre WS- extensions. Det kan fx angives, at der skal benyttes ReliableMessaging, eller bestemte WS-Security metoder. I overensstemmelse med Client Service Contract Policy WSDL Figur 2-4 WSDL med policy WS-Security Da web services typisk befinder sig på netværk, er det afgørende, at der tænkes på sikkerheden. WS-Security definerer en lang række metoder, der kan øge sikkerheden. Dette er alt fra at definere hvilken protokol der skal benyttes (fx HTTPS) til signering af beskeder og kryptering på besked-niveau. 2.2.3 Sikkerhed Da web services er designet til at sendes over netværk, hvor man ikke kan sikre sig mod, at andre lytter med, så er det essentielt, at der benyttes kryptering til at beskytte data med. Der er to måder man kan vælge at benytte kryptering på, nemlig sikkerhed på transport-niveau (Transport level security) og sikkerhed på beskedniveau (message level security). Transport level security Når man lader transport-laget tage sig af krypteringen, så kaldes det transport level security. Et typisk eksempel på dette er HTTPS, der er en variant af HTTP der benytter SSL kryptering, som er baseret på public-key kryptografi.

2.2 SOA 12 Client E D Service kryptering dekryptering Klient computer Åbent netværk Server computer Figur 2-5 Transport level security På Figur 2-5 ses det hvordan kryptering på transportniveau fungerer. I dette tilfælde er der ikke nogen problemer, beskeden er krypteret fra klienten afsender den, til den endelige service modtager den. Problemet opstår når der er mellemliggende services: kryptering dekryptering kryptering dekryptering E D E D Client Service Service a b c d e Figur 2-6 Transport level security med mellemliggende service På Figur 2-6 ses det, at beskeden er krypteret i fase b og d. Men ikke i fase c, hvor beskeden befinder sig hos en mellemliggende service, der skal sende beskeden videre. Dette er problematisk, da det ideelle ville være, at beskeden var krypteret i alle faser mellem a og e. I et system, hvor man har fuld kontrol over alle services ville dette ikke udgøre en større sikkerhedsrisiko, men i mere komplekse systemer kan dette være et stort problem, da man ikke nødvendigvis har kontrol over den mellemliggende service. Message level security Alternativet til transport level security er message level security. I message level security er det ikke muligt at kryptere hele beskeden, da fx informationer om hvor beskeden skal sendes til, ikke kan være krypteret, hvis der er flere mellemliggende led. Tilgengæld vil data der bliver krypteret med message level security kun kunne læses af den endelige modtager. Dette princip kan ses på Figur 2-7, her ses det, at det vigtige data (det grå område i beskeden), er krypteret, mens der stadig er noget gult, der symboliserer den del af beskeden der ikke er blevet krypteret.

13 Analyse kryptering E dekryptering D Client Service Service a b c Figur 2-7 Message level security 2.2.4 Code first/contract first Der er to forskellige udviklingsmodeller, når man skal udvikle en web service. Code first og Contract first. Code first Hvis man vælger code first, så udvikler man sin kode først, og får et værktøj til at genere en WSDL-fil ud fra koden, som vist på Figur 2-8..java java2wsdl Contract.wsdl Figur 2-8 Code first approach Det er meget hurtigt, at udvikle vha. code first metoden, da man blot skriver sin web service som almindelig kode, og man ikke behøver, at designe WSDL-filen i hånden. Det er dog nødvendigt, at være varsom med de datatyper man vælger som input/output til sine kald. Hvis man fx benytter frameworket Apache Axis2, som er Java baseret, så kan det kun eksporterer lister til XML, hvis der tale om arrays. Mens det fx ikke vil virke efter hensigten, hvis man benytter List. Så det er nødvendigt at kode med omtanke, når man laver sine service-klasser. Code first metoden tillader også automatisk opdatering af sin WSDL-fil, når man laver tilføjelser/ændringer i sin web service. Når man har ændret sin kode, så kører man bare sit konverteringsværktøj, og så har man en ny WSDL-fil. Nogle

2.3 Servicens indhold 14 frameworks genererer endda WSDL-filer on-the-fly, fx Axis2. Men betyder også, at man kan lave konflikter med tidligere WSDL-filer uden at opdage det. Også på dette punkt, skal man være meget på vagt, når man laver ændringer i koden. Contract first Hvis man helt styr på sine datatyper, så kan man benytte contract first metoden, hvor man skriver sin WSDL-fil først, og herefter benytter et værktøj til at genere sin kildekode, se evt. Figur 2-9. Dette kan være mere tidskrævende end ovenstående, især for udviklere, der ikke er vant til at lave XML-filer. Men til gengæld, har man en fast defineret WSDL-fil, som kildekoden derefter vil afspejle. Contract.wsdl wsdl2java.java Figur 2-9 Contract first approach 2.3 Servicens indhold For at kunne opstille krav til web servicen, er det nødvendigt først at skabe sig et overblik over hvordan flowet i systemet vil være. Selvbetjeningsportalen har som udgangspunkt ikke selv brugerdata liggende. Dvs. alt brugerdata ligger i Panther Administration Solution, og skal hentes vha. web servicen. Så når en bruger logger ind i selvbetjeningsportalen, skal selvbetjeningsportalen hente brugerinformationerne ud fra det brugernavn, som brugeren har angivet.

15 Analyse 2.3.1 Use case For at skabe et overblik over flowet i systemet, er der lavet en use case, der dækker login proceduren: Use case navn Mål Område Niveau Prækonditioner Login At brugeren kan logge ind på selvbetjeningsportalen. System Primær Brugeren er forbundet til et netværk, der kan forbinde til selvbetjeningsportalen, der videre kan forbinde til Panther Service. Brugeren logges ind i selvbetjeningsportalen Succes postkondition Fejl postkondition Login fejler, brugeren nægtes adgang. Primær aktør Slutkunde (internetbruger) Udløser Bruger ønsker at benytte selvbetjeningsportalen. Normal forløb Trin Aktivitet 1 Brugeren indtaster brugernavn og password i en formular, og trykker send. 2 Selvbetjeningsportalen modtager data, og sender en anmodning til Panther Service om at få brugerinformationer for brugeren ud fra brugernavnet. 3 Selvbetjeningsportalen tjekker om det password, som blev sendt tilbage af Panther Service svarer til det password brugeren sendte. 4 En side sendes tilbage til brugeren, der viser at login var OK. Alternative forløb 2a Selvbetjeningsportalen kan ikke komme i kontakt med Panther Service. En meddelelse sendes til brugeren om, at en systemfejl er indtruffet. Prioritet Ydelse Frekvens 2b 3a Brugeren blev ikke fundet af Panther Service. En fejl sendes til brugeren om, at brugernavn/password er forkert. Passwordet var ikke korrekt. En fejl sendes til brugeren om, at brugernavn/password er forkert. Høj Få sekunder. En gang per brugersession på selvbetjeningsportalen. Mange gange dagligt. Ud fra denne use case, er der lavet et systemsekvensdiagram, der beskriver login flowet. Dette diagram kan ses på Figur 2-10.

2.4 Krav 16 Slutbruger Selvbetjeningsportal Panther Service Login(user, pw) HentBrugerInfo(user) BrugerInfo Resultat Check login Figur 2-10 Systemsekvensdiagram over login Det vil sige, der skal være en metode, der henter brugerinformationer ud fra et brugernavn. Brugeren skal også kunne redigere i disse brugerinformationer (fx rette sit kodeord). Når brugeren er logget ind, er det oplagt, at han skal kunne se de produkter han allerede har købt, og de abonnementer han er tilmeldt. Han skal ligeledes kunne se en liste over de produkter, som han har mulighed for at købe. Og de produkter han har mulighed for at købe/tilmelde sig, skal han selvfølgelig kunne bestille. Det skal ligeledes være muligt at se de tidligere ordre, som kunden har foretaget. 2.4 Krav Krav A. Cross-platform kompatibilitet Klienterne til web servicen udvikles af internetudbyderne. En af de vigtigste forudsætninger for dette projekt, var at internetudbyderne bør kunne lave klienten på deres nuværende løsninger. Panther Applications erfaring er, at disse løsninger primært baserer sig på: PHP.NET

17 Analyse Java Det er derfor meget vigtigt, at det er muligt at der kan laves klienter til disse platforme op mod web servicen. Grundidéen, var at internetudbydere skulle kunne lave en portal hosted hos en almindelig PHP webudbyder. Krav B. Let at bruge Det skal være let at udvikle op mod web servicen uden indgående kendskab til den interne datastruktur i Administration Solution. Det betyder, at en ny intuitiv datastruktur skal opbygges. Krav C. Metoder Det skal være muligt at tilgå følgende metoder: Hent en kunde ud fra et login-navn eller et id. Hent kundens nuværende produkter Hent de produkter, som kunden har mulighed for at købe Rediger kundens grund-data (navn osv) Bestil produkt Hent kundens tidligere ordrer Hent en ordre som PDF-fil Krav D. Web service i Java Web servicen, skal som et led i Panther Applications udviklingsstrategi udvikles i Java. Krav E. Selvbetjeningsportal i PHP Klienten til web servicen, dvs. selvbetjeningsportalen skal udvikles i PHP. Der skal udvikles en prototype med henblik på test, samt som eksempel for fremtidige udviklere. 2.5 Domænemodel For at imødekomme Krav B, er der lavet en ny domænemodel, uafhængigt af de eksisterende datastrukturer fra Panther Administration Solution. Ved ikke at lade domænemodellen afhængige af klasserne fra tidligere løsninger, følges princippet om abstraktion, der er nævnt tidligere i dette kapitel. Dette kaldes den eksterne domænemodel, og kan ses på Figur 2-11.

2.6 Delkonklusion 18 ProductInstance id Er et 1 1 Product id name buyprice subscriptionprice internet phone User * Tilhører 1 id name login password email 1 Har * * Kan købes af * Order id from to generated amounttax amount discount 1 OrderPDF binary 1 Har Figur 2-11 Domænemodel 2.6 Delkonklusion Ud fra problemformuleringen side 4 er følgende punkter gennemgået i analysen: Undersøges hvilke web service teknologier der er tilgængelige. Opstilles krav til systemet. Laves use cases Opstilles services og metoder. Der gennemgået væsentlige teknologier, herunder web services, SOAP, WSDL, SOA og WS-* udvidelser. Der er opstillet en række krav til systemet, og lavet et udkast til hvad servicen skal indeholde samt hvordan den skal fungere.

3 Design Formålet med dette kapitel, er at udnytte de informationer og konklusioner, der blev opstillet i analysen, til at konstruere en arkitektur for systemet, samt at beslutte hvilke teknologier, der skal gøres brug af. Der opstilles en case study, der undersøger understøttelsen af de tidligere angivne teknologier (fx WS-* udvidelser) i systemet. På baggrund af denne case study udvælges de teknologier, der er mulige og nødvendige for systemet. De endelige web service metoder defineres, og systemets arkitektur designes. 3.1 Case study 1: Web service understøttelse 3.1.1 Formål Formålet med denne case study, er at få klarlagt hvilke muligheder, der er for at benytte web services på de forskellige platforme, som dette projekt fokuserer på: PHP,.NET og Java. 3.1.2.NET platformen.net har omfattende understøttelse af web services. Hvis man installerer Visual Studio 2008, så har man filen wsdl.exe til rådighed, der kan lave en web service klient ud fra en wsdl-fil. Fx wsdl /out:proxy.cs /l:cs http://localhost/services/service?wsdl Ved brug af denne kommando, genereres der en proxy klasse Proxy.cs, som benyttes til at forbinde til web servicen. Før.NET 3.0 var der dog ingen indbygget understøttelse for WS standarder som fx WS-Security. Men til disse ældre versioner, har Microsoft udgivet et framework kaldet Web Service Enhancements, der understøtter de samme standarder, som.net 3.x. I.NET 3.x understøttes disse standarder nemlig i kraft af Windows Communication Foundatation.

3.1 Case study 1: Web service understøttelse 20 3.1.3 PHP Webservices understøttes som standard I PHP vha. modulet SOAP. Dette er et almindeligt modul i PHP, og erfaring viser, at de fleste udbydere har dette modul stået til. Hvis man administrerer sin egen server, er det let at tilføje dette modul. Men SOAP modulet i PHP understøtter ikke WS-* extensions. Firmaet WSO2 har lavet et framework 6, der bl.a. virker i PHP. Ulempen er, at man skal bruge et PHP modul til det, og det vil man selv skulle compile. Denne metode vil derfor kun virke, hvis man selv har fuld kontrol over PHP installationen. Dette vil man ikke have, hvis man har hosted sin PHP løsning hos en ekstern udbyder, og det er derfor ikke en mulighed, at benytte WSO2 s løsning. For at lave en SOAP klient i PHP benyttes klassen SoapClient. Et SOAP kald kan laves således: <?php $client = new SoapClient("http://www.example.org/service/service.wsdl"); $result = $client->fetchcustomer( login ); Men SoapClient understøtter som tidligere nævnt ikke at man benytter WSextensions. Der er dog enkelte WS-extensions, der er simple nok til at de stadig kan benyttes i PHP. Fx WS-Security UsernameToken er så simpel, at det blot er en stump XML, der skal indsættes i SOAP headeren. Dette kan gøres ved at lave en ny klasse, der arver fra SoapClient. Når der i ovenstående tilfældes kaldes client->fetchcustomer, vil SoapClient kalde metoden dorequest, der er beskrives således i PHP s dokumentation: Performs SOAP request over HTTP. This method can be overridden in subclasses to implement different transport layers, perform additional XML processing or other purpose. Og det er netop additional XML processing der er krævet, for at indsætte en UsernameToken i headeren. Der laves derfor en ny klasse PantherClient, der nedarver fra SoapClient: <?php class PantherClient extends SoapClient {.. public function dorequest($request, $location, $action, $version) { 6 http://wso2.com/products/create/wso2-web-services-framework/

21 Design $dom = new DOMDocument("1.0"); $dom->loadxml($request); $securityheader = $dom->getelementsbytagname("security");.. // Construct UsernameToken Header $usernametoken = $dom->createelementns($this- >securityextns, "UsernameToken"); $username = new DOMElement("Username", $this->username, $this->securityextns); $password = $dom->createelementns($this->securityextns, "Password"); $typeattr = new DOMAttr("Type", $this->passwordtype); $password->appendchild($typeattr); $password->appendchild($dom->createtextnode($this- >password)); $usernametoken->appendchild($username); $usernametoken->appendchild($password); // Construct Security Header $securityheader->appendchild($usernametoken); // Save the XML Request $request = $dom->savexml(); } return parent:: dorequest($request, $location, $action, $version); } I denne klasse, er der desuden en constructor, hvor man kan videregive brugernavn og kodeord: new PantherClient( wsdlfile.wsdl, username, password ). Vha. denne klasse bliver der tilføjet et securityelement til SOAP headeren: <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope...> <SOAP-ENV:Header> <ns2:security SOAP-ENV:mustUnderstand="1"> <ns2:usernametoken> <ns2:username>bob</ns2:username> <ns2:password Type="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-username-tokenprofile-1.0#PasswordText">bobPW</ns2:Password> </ns2:usernametoken> </ns2:security> </SOAP-ENV:Header> <SOAP-ENV:Body>... (det indsatte er med fed) Det er altså muligt, at benytte UsernameToken i PHP. Desværre kræver det, at man selv implementerer funktionaliteten, men dette er nu gjort, og dette eksempel kan gives videre til de internetudbydere der ønsker at benytte PHP.

3.1 Case study 1: Web service understøttelse 22 3.1.4 Java I Java er der en række open source initiativer, der giver mulighed for at forbinde til web services med WS-extensions. Fx Apache Axis2. Desuden har alle større software leverandører også Java-løsninger til rådighed, fx IBM og JBoss. Så hvad enten man vælger at gå open source eller benytte leverandøre, så er der gode muligheder i Java. Hvis man tager udgangspunkt i Apache Axis2, så ses det på deres website 7, at de understøtter WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-Security og WS-Addressing. I Java er der altså god understøttelse for web service udvidelserne. 3.1.5 Konklusion Det er undersøgt hvorledes det kan lade sig gøre, at benytte WS-extensions på de tre platforme, som der er fokus på i Krav A:.NET, Java og PHP. Da alle disse tre sprog skal understøttes, er den eneste mulighed at følge den laveste fællesnævner, der er PHP. Dvs. at nogle WS-extensions ikke kan benyttes. Fx WS- ReliableMessaging. Mens andre stadig kan benyttes. Det giver god mening, at benytte WS-Policy til fx at definere hvad kommunikation med web servicen skal fungerer. For selvom PHP ikke understøtter det, så vil den korrekte kommunikationsmetode stadig stå i WSDL filen, som en udvikler vil kunne læse manuelt og følge. Sikkerhedsmæssigt, ville det have været oplagt at benytte message level security, herunder kryptering, fra WS-Security. Dette kan i midlertidigt ikke lade sig gøre i PHP, men transport level security vil i de fleste tilfælde være tilstrækkelig sikkert. I dette projekt, vil kryptering derfor blive gjort vha. transport level security. Det er muligt, at flere internetudbydere kan logge på samme web service. Derfor skal hver internetudbyder kunne identificeres vha. et brugernavn, og autentificeres vha. et password. Dette understøtter WS-Security vha. UsernameToken, som jo godt kunne benyttes fra PHP, grundet den simple opbygning. 7 http://ws.apache.org/axis2/

23 Design 3.2 Arkitektur 3.2.1 Services Ud fra Krav C i analysen, er der følgende kald, som web servicen skal understøtte: Hent en kunde ud fra et login-navn eller et id. Hent kundens nuværende produkter Hent de produkter, som kunden har mulighed for at købe Rediger kundens grund-data (navn osv) Køb produkt Hent kundens tidligere ordrer Hent en ordre som PDF-fil Vha. domænemodellen side 18, kan disse kald opskrives i en tabel. Typerne i tabellen er fra domænemodellen Figur 2-11. FetchCustomer Input Output Beskrivelse username User Hent information om kunden. Dvs. navn, eller adresse, telefonnummer osv. user id SaveCustomer Input Output Beskrivelse User N/A Gem kundens opdaterede informationer. FetchProducts Input Output Beskrivelse User id ProductInstance[] Hent kundens nuværende produkter. Et eksempel kunne være en 5Mbit ADSL forbindelse, og et ADSL Modem. FetchAvailableProducts Input Output Beskrivelse User id Product[] Hent de produkter som kunden har mulighed for at købe. Fx 100 Mbit Fiber. FetchOrderList Input Output Beskrivelse User id Orders[] Hent kundens tidligere ordre-liste. FetchOrder Input Output Beskrivelse Order id Streng (base64) Hent en enkel ordre som en PDF-fil.

3.2 Arkitektur 24 OrderProduct Input Output Beskrivelse User id, ProductInstance Product Bestil et produkt. 3.2.2 Samarbejde med Panther Admin Mens de fleste af metoderne, der skal implementeres er forholdsvis simple, er metoderne FetchOrder og OrderProducts det bestemt ikke. FetchOrder kræver PDFgenerering, som kræver en del kode, og som de forskellige internetudbydere ofte opdaterer. OrderProducts, der kaldes når en kunde køber/tilvælger et produkt, skal automatisk sætte nogle processer i værk, der fx kan gøre en kundens internet hurtigere, sørge for at en kunde for tilsendt sit modem osv. Begge disse operationer findes allerede i Panther Administration Solution, og at udvikle metoderne på ny i Panther Service, ville ikke bare øge udviklingstiden dramatisk, men også øge fejlrisikoen og forøge vedligeholdelsesomkostninger markant. Derfor vil kald til disse metoder blive videresendt til en web service i Panther Administration Solution. Det er klart, at beskeden ikke vil kunne videresendes direkte, da datamodellen i Panther Service web service ikke er lig datamodellen for web servicen i PAS. Så Panther Service vil stadig skulle bearbejde dataet. Selvbetjening Panther Service hvis FetchOrder eller OrderProduct Panther Administration Solution ellers Figur 3-1 Kald bliver videresendt til Panther Administration Solution

25 Design 3.2.3 Arkitekturoversigt På nuværende tidspunkt er alle grundelementerne i systemet defineret, for at skabe et overblik, er der Figur 3-2 vist en oversigt over arkitekturen. DB2 Panther Administration Solution Persistance Service SOAP klient Web Service Framework Panther Service SOAP klient Web sider HTTP Server Selvbetjeningsportal Browser Figur 3-2 Arkitekturoverigt

3.2 Arkitektur 26 3.2.4 Systemets lag Et overordnet overblik over Panther Service, ses på Figur 3-3. View Customer Service Domain User Product ProductInstance Order Technical Services Persistance Web Service Framework Figur 3-3 Panther Service arkitekturlag Grænsefladen til servicen er Customer Service, domæneklasserne ligger i Domain, og der skal bruges et persistance framework til at håndtere hvordan data gemmes og læses. Herudover skal der bruges et Web Service Framework, der kan gøre Customer Service tilgængelig som en service. Selvbetjeningsportalen i dette projekt er meget simpel. Den understøtter kun de features, som Panther Service stiller til rådighed. Selvbetjeningsportalen har følgende sider: Login Ordrer Nuværende produkter Butik Kundeinformation Domænet er det samme, som i Panther Service. Arkitekturen for selvbetjeningsportalen er vist på Figur 3-4.

27 Design View Template Orders Products Shop Login Customer Application Session Controller Domain User Product ProductInstance Order Technical Services SOAP Figur 3-4 Selvbetjeningsportalens lag Kerneelementerne i selvbetjeningen er sessionsstyring og controlleren. I view findes siderne der skal fremvises, samt template-systemet. Selvbetjeningsportalen skal blot bruges som eksempel for internetudbydere, og der er derfor ikke grund til at gå yderligere i detaljer med designet af denne. 3.2.5 Klasse- og sekvensdiagram For Panther Service er der lavet et klassediagram, der visser klasserne i systemet, samt hvilke metoder der er i de enkelte klasser. Customer-klassen er den klasse hvor servicekaldene bliver videresendt til.

3.2 Arkitektur 28 com::pantherapplications::service::services::customer fetchcustomer(login : String) : User fetchorderpdf(orderid : int) : String fetchorderlist(userid : int) : Order[] fetchproducts(userid : int) : ProductInstance[] fetchavailableproducts(userid : int) : Product[] orderproduct(userid : int,productid : int) : ProductInstance savecustomer(user : User) : boolean com::pantherapplications::service::domain::user 1 1 1 1 0..* com::pantherapplications::service::domain::productinstance instanceid : int id : int name : String login : String password : String email : String orderproduct(product : Product) : ProductInstance validate() : void save() : UserDAO getorders() : Order[] getproducts() : ProductInstance[] getavailableproducts() : Product[] 1 0..* com::pantherapplications::service::domain::product id : int name : String buyprice : int subscriptionprice : int internet : boolean phone : boolean dao : ProductDAO 1 1 1 0..* com::pantherapplications::service::domain::order id : int from : int to : int generated : int amountwithouttax : long amountwithtax : long discount : long dao : BLOrderHeaderDAO getpdf() : String 1 1 com::pantherapplications::service::domain::pasproxy 1 orderproduct(usr : User,product0 : Product) : ProductInstance fetchorderpdf(order : Order) : String Figur 3-5 Klassediagram over Panther Service På figur Figur 3-6 og Figur Figur 3-7 er der lavet systemsekvensdiagrammer, hvor det ene fokusere på scenariet, hvor der kun kommunikeres med DB2 databasen, mens det andet også benytter Panther Admin til OrderProduct.

29 Design Slutbruger Selvbetjeningsportal Panther Service Hibernate DB2 GET FetchCustomer get(customer.class) SELECT.. ResultSet Customer User FetchProducts User.getProducts SELECT.. ResultSet Product[] Products HTML Figur 3-6 Systemsekvensdiagram for FetchCustomer og FetchProducts

3.2 Arkitektur 30 Bruger Selvbetjening Panther Service Hibernate DB2 PAS GET FetchCustomer get(customer.class) SELECT ResultSet Customer User OrderProduct product_add CustomerProduct ProductInstance HTML Figur 3-7 Systemsekvensdiagram der inkluderer et kald til PAS. Ud over systemsekvensdiagrammerne, der beskriver flowet i hele systemet, er der lavet et sekvensdiagram, der viser eksempel på flowet i klasserne i Panther Service. Dette er vist på Figur 3-8.

31 Design Customer User Order PASProxy new User(username) User orderproduct orderproduct ProductInstance ProductInstance getpdf FetchOrderPDF String String Figur 3-8 Sekvensdiagram for Panther Service. 3.3 Delkonklusion I dette kapitel er der opstillet en arkitektur for systemet. Det er valgt, at der benyttes Axis2, som web service framework og Hibernate som ORM system. På baggrund af en case study, er det besluttet, at der ikke benyttes avancerede WS standarder, da PHP klienter i så fald ikke ville kunne tilgå servicen. De enkelte service-kald er beskrevet, og der er opstillet diagrammer for hvorledes systemet bør virke.

4 Implementering og test I dette kapitel gennemgås et case study, der fungerer som en tidlig iteration, hvor det testes at systemet vil virke i praksis. Herefter gennnemgås implementering og test for henholdvis Panther Service og selvbetjeningsportalen. 4.1 Case study: Systemopsætning Som start på udviklingen, er der lavet en case study, der undersøger hvorvidt der er noget, der ikke kan lade sig gøre, eller om der er noget der ikke er taget højde for. Der skal bruges case studies til at nærstudere følgende: Cross platform kompatibilitet Samarbejde med PAS Udvidelsesmuligheder Sikkerhed Til dette formål vil der implementeres tre servicekald: FetchCustomer OrderProduct Cross platform kompatibilitet kan testes ved at benytte FetchCustomer i forskellige sprog. Sameksistens med eksisterende løsninger testes ved at benytte OrderProduct, der kalder PAS, jævnfør afsnit Error! Reference source not found.. 4.1.1 Benyttet software Axis2 Som Web Service Framework benyttes Apache Axis2/Java. Axis2 er et framework, der både benyttes til at udstille web services, samt til at udvikle klienter med. Axis2 er lavet i Java (der findes dog også en C-udgave), og service-delen er lavet som en servlet. Dvs. den kræver en servlet container, som der heldigvis findes masser af. Til Panther Service vil Axis2 først og fremmest benyttes til at udstille servicen med. Men klient-delen af Axis2 vil også blive benyttet til at forbinde til PAS. Axis2 understøtter både code first og contract first, som er beskrevet på side 13. Hvis man allerede har sin service-klasse, så kan man bare konfigurerer Axis2 til at deploye metoder i den klasse. Så sørger Axis2 selv for at udstille en WSDL-fil

4.1 Case study: Systemopsætning 34 dynamisk. Hvis man i stedet starter ud med en WSDL-fil, så findes WSDL2Java værktøjet 8 til dette formål. Hibernate For at tilgå til det eksisterende datalag, som på nuværende tidspunkt er en DB2 database, benyttes der et persistence framework. Til formålet er valgt Hibernate, der er et ORM framework lavet i Java. ORM, Object-relational mapping, er en teknik, der forbinder data fra en database med objekter i et system. Hibernate understøtter de fleste databaser gennem JDBC, og kan både tilgå databasen vha. O/R mapping, SQL eller sit eget SQL-lignende sprog HQL. Ved at benytte Hibernate spares der hurtigt meget udviklingstid, og koden bliver ikke så DB2 specifik. Dvs. hvis firmaet på et tidspunkt vælger at ændre databasen, vil det, hvis man ikke har brugt SQL i Hibernate, kun være en konfigurationsfil der skal ændres. Hibernate understøtter derudover caching, connection pools og meget mere. 4.1.2 Samarbejde med PAS PAS har en web service grænseflade kørende, hvor metoden product_add findes i forvejen, som kan benyttes til OrderProduct. product_add har følgende parametrer, der skal angives: customerid, kundens id. accountid, kunder er medlem af en kundegruppe. Dette er ID et på denne gruppe. productident, dette er en identifikationsstreng for produktet. Ikke det samme som et id, men ligger i samme tabel i databasen. startdate connid, hvilken internetforbindelse produktet skal knyttes til. Vil typisk skulle sættes til auto. De eneste input, som OrderProduct har, er kundens id og produktets id. Ud fra dette skal der altså først laves nogle databaseforespørgsler, for at få gruppe id et, og produktets identifikationsstreng, som kan gøres uden problemer. Det er først muligt at tilgå PAS, når PAS er konfigureret til at tillade IP-adressen som web service klienter kalder fra. 8 http://ws.apache.org/axis2/tools/1_2/eclipse/wsdl2java-plugin.html

35 Implementering og test 4.1.3 Sikkerhed Sikkerheden i case study testen er baseret på transport level security, i dette tilfælde på HTTPS. Alle sprog understøtter dette gnidningsfrit, da det er så almindeligt. For Panther Service er det servlet containeren (Apache Tomcat under denne case study) der skal opsættes til at benytte HTTPS. Ud over HTTPS benyttes UsernameToken også, som ligeledes er understøttet af alle sprog. 4.1.4 Case study konklusion Denne case study har vist, at de vigtigste elementer i systemet vil fungerer i praksis. Systemet vil understøtte klienter fra PHP, Java og.net. Sikkerhed i form af HTTPS og UsernameToken benyttes. Der kan kommunikeres med Panther Administration Solution, og benyttes dette systems eksisterende funktionalitet, og datatyper er fremtidssikret i og med, at der kan ske tilføjelser til disse uden det påvirker systemer, der ikke er opdateret med den nyeste version af disse typer. 4.2 Panther Service I dette afsnit beskrives det hvorledes Panther Service er implementeret. Arkitekturen er beskrevet på Figur 4-1, der er en tilrettet version af Figur 3-2 (arkitekturoversigt), da der nu er angivet hvilket software der er benyttet. Fx Hibernate benyttet som Persistance.

4.2 Panther Service 36 DB2 Panther Administration Solution Hibernate Axis2 klient Service Axis2 Apache Tomcat web service request Figur 4-1 Arkitekturoversigt for Panther Service 4.2.1 Apache Tomcat Som servlet container er Apache Tomcat benyttet. Den eneste konfiguration der er lavet, er HTTPS opsætningen, der krævede en lille ændring i filen server.xml: <Connector SSLEnabled="true" clientauth="false" maxthreads="150" port="8443" protocol="http/1.1" scheme="https" secure="true" sslprotocol="tls"/> Herudover skal der oprettes en keystore i Java, for at lave krypteringsnøgler: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA 4.2.2 Apache Axis2 For at deploye en service i Axis2, skal der under mappen axis/web-inf/services/ lægges en mappe med servicens kompilerede klassefiler. Herudover skal

37 Implementering og test konfigurationsfilen META-INF/services.xml placeres i mappen. Denne fil definerer hvilken klasse, der skal fungerer som servicens grænseflade, samt hvordan servicen skal fungere. I denne fil er der også defineret en WS-Policy der angiver, at der forventes en WS-Security UsernameToken, samt at forbindelsen skal være HTTPS. For at understøtte WS-Security UsernameToken benyttes modulet rampart, der implementerer WS-Security funktionalitet i Axis2. Når klienten sender en UsernameToken, bliver denne token verificeret af en callback-klasse, der angives i services.xml. 4.2.3 Hibernate Hibernate opsættes ved hjælp af filen Hibernate.cfg.xml. Her angives databaseinformationer og diverse indstillinger, fx om der skal benyttes caching. Mapping mellem databasetabeller og klasser foregår ved at benytte annotiations i data-klasserne, der ligger i dao pakken. Styrken ved Hibernate, er at man ved hjælp af simple annotiations kan skabe sammenhænge mellem klasser, helt uden brug af SQL. Fx ses det, at UserDAO klassen har følgende stump kode: @OneToOne(mappedBy = "user") private CustomerDAO customer; Hvis man skal bruge userdao.customer, ved Hibernate, at den skal benytte den pågældende UserDao s id, og lave et SQL-kald, der finder hvilken CustomerDAO der har den samme værdi i user feltet. Dette kan være kompliceret at forklare i tekst, men det virker, og man kan lave stortset alle database-operationer vha. disse mappings. For at starte Hibernate samtidigt med servlet containeren, således at den første bruger ikke skal vente på at der bliver forbundet til databasen, benyttes Tomcats web.xml konfigurationsfil, hvor der indsættes en listener, der henviser til HibernateListener, der sørger for at initialisere Hibernate. Der benyttes en singleton-klasse, HibernateUtil, der sørger for, at der kun er en instans af Hibernate.

4.2 Panther Service 38 4.2.4 Databasestruktur Tabellerne for produkter og brugere i PAS, er en smule forvirrende, og vil derfor kort blive gennemgået her. En kunde ligger i to tabeller. Customer og User. Det er ikke fuldstændig klart hvorfor, men af historiske årsager er det splittet op i to tabeller. Et produkt er beskrevet i ProductConf. En instance af et produkt er beskrevet i CustomerProduct. Dvs. når man opretter et nyt produkt, så ligges det i ProductConf, og når en kunde køber produktet, så ligges dette i CustomerProduct. En kunde tilhører altid en gruppe. Sådanne grupper er beskrevet i CustomerGroup. Grupper er inddelt hierarkisk, så en gruppe kan altså have en moder -gruppe. Da nogle produkter kun skal kunne købes af bestemte grupper, så er der en tabel der hedder CustomerGroupProduct, der beskriver hvilke grupper der kan købe hvilke produkter. Denne databasestruktur, der er beskrevet ovenfor er ligeledes afbilledet på Figur 4-2 Customer 1 0..1 User 1 * 1 CustomerGroup 1 * CustomerProduct 0..1 1 * CustomerGroupProduct * 1 * 1 ProductConf Figur 4-2 Databaserelationer i PAS 4.2.5 Udviklingsmiljø Projektet er udviklet i Eclipse 9, hvor Java EE versionen er benyttet. Det betyder, at Tomcat kan integreres i Eclipse, og at man let kan starte og stoppe web servicen. Eclipse har desuden JUnit understøttelse, så unit-tests kan køres direkte fra Eclipse. 9 http://www.eclipse.org/

39 Implementering og test For at gøre det lettere at builde projektet uden Eclipse, så er der også udviklet en Ant build file. For at kompilere projektet tilrettes build.xml og kommandoen ant køres. Dette er yderst brugbart, hvis man fx ønsker at lave et checkout af projektet på en server eller lign, hvor Eclipse ikke er tilgængelig. Figur 4-3 Eclipse IDE 4.2.6 Afhængigheder Følgende Java libraries er benyttet i Panther Service: Axis2 10 Rampart (Axis2 modul) 11 IBM DB2 JDBC driver Hibernate 3 12 10 http://ws.apache.org/axis2/ 11 http://ws.apache.org/axis2/modules/rampart/1_3/security-module.html 12 http://www.hibernate.org/

4.2 Panther Service 40 JUnit 3 13 For at benytte kildekoden i Panther Service, skal disse libraries inkluderes i Java s classpath. Det er op til læseren selv at skaffe disse libraries, de er ikke distribueret med projektet. 4.2.7 Unit Tests Der er løbende lavet unit tests i Panther Service vha. JUnit. Disse tests ligger under com.pantherapplications.service.test, og der er tests for alle metoderne i servicen. Det skal bemærkes, at flere af disse tests kræver database-adgang og tests af metoderne FetchOrderPDF og OrderProduct, ligeledes kræver adgang til PAS Servicen testes internt i disse unit tests. Der testes altså på indersiden af servicen, dvs. det er kun servicens klasser der testes. Servlet indstillinger osv. vil ikke have nogen betydning i dette tilfælde. 13 http://www.junit.org/

41 Implementering og test Figur 4-4 Screenshot af JUnit test Udover denne test, er der test af selve web servicen (dvs. kald udefra) i afsnit 4.3.2.

4.3 Selvbetjeningsportalen 42 4.3 Selvbetjeningsportalen Selvbetjeningsportalen er opbygget i PHP, som ligger på en Apache webserver. Der er et screenshot af selvbetjeningsportalen på Figur 4-5. Figur 4-5 Screenshot af webshoppen i selvbetjeningsportalen 4.3.1 Filoversigt Selvbetjeningsportalen er bygget meget simpelt op. Filerne, som browseren tilgår ligger i roden, fx index.php, shop.php. Disse filer sørger for, at include/header.php bliver kaldt, og denne fil sørger for at indlæse diverse klasser og libraries. Filen include/pantherclient.php er den fil, der extender PHP s egen SoapClient, og tilføjer WS-Security UsernameToken til kaldet. Mappebeskrivelse: