Stokermonitor. Webprojekt 2008 Datalogisk Institut, Aarhus Universitet Forelæser: Kristian Bisgaard Lassen Dato: 28. Marts 2008

Transkript

1 Stokermonitor Webprojekt 2008 Datalogisk Institut, Aarhus Universitet Forelæser: Kristian Bisgaard Lassen Dato: 28. Marts 2008 Projektgruppe: Thomas Daugaard Kim Stenbryggen Rune Skou Larsen Stokermonitor 1

2 Indledning Dette er projektrapporten og dermed den ene del af projektgruppens besvarelse, som udover rapporten indbefatter et kørende prototype-system samt kildekoden hertil. Projektgruppens besvarelse består af 3 dele: Projektrapporten - dette dokument En eksekverbar prototype inkl. kildekode - vedlagt som stokermonitor.zip Opsætningsvejledning - appendix 1 i dette dokument Projektgruppen består af: Thomas Daugaard Kim Stenbryggen Rune Skou Larsen Besvarelsen er udarbejdet i 3. og afsluttende del af fagpakken XML og Web Teknologi ved Aarhus Universitet. Problemområde Projektgruppen har udviklet en prototype på et Web- og XML-baseret styringssystem til stokerfyr. I det følgende gives en introduktion til stokerfyr, samt en opridsning af problemområdet med Web- og XML-baseret styring heraf. Stokerfyr Et stokerfyr er et fyr, der brænder fast brændsel i form af træpiller, korn og lignende for at opvarme vand til centralvarme og evt. brugsvand. Stokerfyr er populære pga. lav brændselspris, CO2-neutral brug af biobrændsel og endeligt det særlige stoker-arrangementet, som gør at fyret kan køre automatisk længe. Figur 1: Skitse af Stokerfyr 1. Styringsenhed (TM3007, udviklet af elektronikvirksomheden Techno-Matic A/S i Hornum). 2. Brandkammer 3. Snegl fungerer som "fyrbøder" (engelsk: stoker) ved at fremføre brændsel til brandkammeret. 4. Tragt til brænsel. Stokermonitor 2

3 Web-styring Udover stokerfyret består systemet af en central web server samt brugerne. Systemkonteksten for web-styrings-systemet er illustreret på figur 2 herunder. Figur 2: Systemkontekst Stokerfyret kommunikerer gennem sin elektroniske styringsenhed over internettet med web serveren og brugerne. Web serveren kommunikerer også direkte med brugerne. Forretningsmuligheder Den forretningsmæssige baggrund for, at udvikle et web-styringssystem til styringsenheden TM3007 for stokerfyr er, at Techno-Matic's kunder har udtrykt ønske om at fjernbetjene fyrene. Det vil sige, at de firmaer, der servicerer stokerfyrene ikke nødvendigvis skal være fysisk tilstede for at foretage ændringer på styringsenhedens opsætning. Desuden vil overvågningen af fyrets drift lettes ved at driftsdata automatisk sendes til en web server hvorved kunden selv eller et service-firma kan fjernovervåge driften. Oftes vil det være sådan, at opstart, overvågning, vedligeholdelse og drift varetages af et service-firma. Dette firma vil ofte være det samme, som har solgt fyret til kunden. Stokermonitor 3

4 Use cases og afgrænsning Aktører Systemet har 4 aktører, der kan tage forårsage hændelser, som systemet skal reagere på. Fyr Producent (Techno-Matic) Service-firma Kunde Use cases På nedenstående UML use case-diagram ses et overblik over de vigtigste use cases, som et komplet system består af. Figur 3: Use cases Projektgruppen har valgt ikke at fokusere på en bred og omfangsrig prototype, men i stedet en prototype, der demostrerer kursus-relevant XML og Web-teknologi. Derfor er kun use cases vedrørende fyrets logning implementret i prototypen. Detaljeret Use case-liste På den detaljerede use case-liste er de implementerede use cases markeret med grøn. Aktør: Fyr Send log om tilstande Alarmer skal sendes fra styringsenheden hvis bestemte predefinerede grænseværdier overskrides. Dette kunne for eksempel være, en temperatur, der overskrides i mere end 5 minuter. Alarmen der sendes, skal eventuelt sendes til en service medarbejder per SMS samtidig med at alarmen logges i en alarm event fil for fyret. Evt. forespørg konfiguration Stokermonitor 4

5 Aktør: Techno-Matic Oprettelse af nyt service-firma. Redigering af service-firma Sletning af service-firma Konfiguration af adgang til system for service-firma. Sikkerhedsopsætning, således at kun autoriserede firmaer (personel) kan lave ændringer på en konfiguration. De forskellige service-firmaer må ikke kunne få adgang til hinandens kunder og deres opsætninger. Techno-Matic skal i princippet have adgang til alle data og funktionaliteter. + alle use cases under "Aktør: Service-firma" Aktør: Service-firma Send driftskonfiguration til fyr. Herunder evt. hvilke data, fyret skal logge og hvordan logningen skal foregå. Tænd og sluk fyr Monitorer logs Overvåg fyr Modtag besked hvis fyr ikke har afsendt log data indenfor et givet tidsinterval. Evt. ekstra udfordring: Google maps, lokation af fyr. + alle use cases under "Aktør: Kunden" Aktør: Kunden Adgang til egne driftsdata. (Forbrugsstatistik) Opgaveafgrænsning Den opgave som, med dette projekt skal løses er: At udvikle et web styringssystem til stokerfyrstyringsenheden TM3007, således at brugerne af stokerfyret kan overvåge fyret via internettet. Opgaven indbefatter udvikling af brugergrænseflade, lagring af data (XML format) i filsystem, opsætning af web server, mockup af TM3007 samt Web Service kommunikation hermed. Løsningsarkitektur I dette kapitel beskrives den udviklede løsnings arkitektur. Stokermonitor 5

6 Beskrivelse af system TM 3007 Styreenhed som skal kunne sende statistikdata og hændelse til vores webserver, og modtage instruktioner herfra. Webserver Skal kunne modtage data fra styreenhederne og gemme dem i et brugbart format. Brugernes rettigheder skal kunne tilpasses, så forskellige typer brugerer kan få adgang til de data som er relevant for dem. Webserveren skal også holde styr på styreenhederne og kunne alarmere brugerne, hvis der er behov for det. Brugere Som udgangspunkt har fundet tre brugertyper - Techno-Matic - Servicefirma - Kunden (der har købt fyret). Storage Vi har valgt at vores storage i prototypen vil bestå af nogle xml-dokumenter. I et endeligt produkt vil man formentlig vælge, og benytte en relationel database. Ved ikke at have et database lag, bliver det lettere at distribuere koden mellem projekt deltagerene og skolen. Håndteringen af flere samtidige brugere er et problem med denne løsningsmodel, men det vil blive løst ved at tilføje en relationel database. Prototypen vil ikke tage højde for om flere samtidige brugere skrive i vores storage. Afviklingsplatform Det udviklede web system afvikles på en teknologistak bestående af Java SE 6, Tomcat JEE Web Server og Axis2 som det ses på figur 4. Stokermonitor 6

7 Figur 4: Afviklingsplatform ROOT.war udstiller brugergrænsefaden, som er baseret på JSP og det moderne præsentationsrammeværk Ext 2.0 axis2.war udstiller den udviklede web service til at modtage logning fra fyret. Den er baseret på WSDL, XML Schema og implementret med apache Axis 2. De to webapplikationer, ROOT.war og axis2.war anvender fælles kode i stokermonitor.jar til at tilgå persistente data. Data persisteres i filsystem i filer indeholdende xml samt samlinger af xml-fragmenter. Sekvensdiagram for logning Stokermonitor 7

8 Designbeskrivelser I dette kapitel gennemgås designet af hhv. brugergrænseflade, Web Services og Persistens. Brugergrænseflade Ext XSLT Datamodel Fysisk struktur Denne sektion beskriver den fysiske struktur af datamodellen, som anvendes i stokermonitor systemet Introduktion Serveren i stokermonitor-systemet skal have mulighed for at gemme visse data omkring de fyr, som overvåges. De hovedgrupper af data, som skal gemmes, er: Konfigurationer til fyr Logfiler fra fyr Som teknologi til at gemme disse data, vælges XML, da vi så har mulighed for at prøve teknologien af i praksis. Vi anvender en almindelig filstruktur til vores XML dokumenter. Vi vil bruge XML Schema som skemasprog, da det er meget vidt udbredt, er kendt af os fra kurset og er i stand til at udtrykke de ting, vi ønsker. Efter lidt iterativ og prototypeudvikling konstaterede vi, at det vil være hensigtsmæssigt at gemme stamdata om de fyr, som er aktive i systemet, og vi tilføjede derefter en hovedgruppe mere: Registrationer af fyr Det er de 3 ovenstående hovedgrupper af data, som uddybes i denne sektion. Logfiler Logs sendes kontinuerligt fra fyr til serveren - dog med pauser imellem. Dette betyder, at mængden af logs vil vokse ret hurtigt. Der fremstod hurtigt følgende problemstillinger: 1. Hvordan tilføjes en ny log nemt i filstrukturen 2. Hvordan kan man effektivt lave forespørgsler i logs fra et enkelt fyr ad. 1: Problemet er, at en ny log skal gemmes i filstrukturen, og det vil være naturligt at gemme alle logs fra et fyr i én fil, da antallet af filer ellers vil eksplodere. Samtidig vil forespørgsler ned i data for et fyr hurtigt blive langsomme (med mindre man ligger semantik på filnavne eller -struktur, hvilket vi som hovedregel vil undgå). Hvis en ny log skal tilføjes i en enkelt fil med alle fyrets logs, skal filen parses for at loggen kan tilføjes indenfor et rodelement, som jo skal eksisterer i et XML dokument. Dette er ineffektivt, Stokermonitor 8

9 og en manuel kodning af tilføjelse til sådan en fil vil hurtigt kunne besværliggøres af encoding problemer, hvorved man risikerer ugyldig XML. Løsningen blev fundet ved, at vi opretter to XML Schema skemaer til to former for indhold: Et for alle logs for et fyr, og et for en enkelt logindgang. Skemaet for alle logs anvender så blot skemaet for en enkelt logindgang ved at det definerer en liste af disse. Skemaet for alle logs kan ses i kildekoden (xsd\furnacelogs.xsd) og skemaet for en enkelt log (xsd\logentry.xsd). Ved hjælp af disse skemaer, kan en enkelt logentry valideres op imod skemaet for en enkelt log, når den ankommer og samtidig være gyldig i den samlede fil, som beskrives af skemaet for alle logs. Problemet med at tilføje en enkelt log til filen eksisterer stadig, men løses ved at lave en "main" log fil for hvert fyr. Denne "main" logfil inkluderer så tekstuelt en almindelig tekstfil af en sekvens af enkelte logs vha. DTD ENTITY faciliteten. Resultatet er, at når man appender en ny logentry (som er valideret) til tekstfilen, som inkluderes i "main" logfilen, at man har et samlet billede af alle logs i denne samtidig med at append af nye logentries er nemme og effektive. Vi undgik desværre ikke helt at ligge semantik på logfilerne, men det er minimeret. ad. 2: Med potentielt mange logs i et log XML dokument for et fyr, er det ganske naturligt at holde sig til en metode som anvender streaming (f.eks. SAX) når filen skal læses. JDOM ville sandsynligvis kræve for meget hukommelse, da denne teknologi indeholder hele strukturen i hukommelsen. Desværre havde vi tekniske problemer med at få en SAX parser til at lave en identity transformation af "main" logfilen, da den ikke fortolkede DTD entiteter (som de enkelte logs er inkluderet med). Dette skulle anvendes i metoden getlogentries på FurnaceStorage, som skal levere et XML dokument, som valideres af Skemaet for alle logs. Vi anvendte derfor en JDOM XMLOutputter i stedet, som udfører det korrekt. Konfigurationer Et fyr skal have adgang til en konfiguration, som fortæller, hvorledes fyret skal forholde sig til varierende temperatur og iltindhold. Konfigurationen er ikke særlig stor og skal altid manipuleres individuelt, og kan derfor med fordel repræsenteres vha. JDOM. Der anvendes også JAXB til nemt at kunne manipulere konfigurationer uden kendskab til brugen af JDOM API'et. Konfigurationer er beskrevet med XML Schema skemaet, som er placeret i kildekoden under "xsd\furnaceconfig.xsd". Registrationer Af datafortolkningsmæssige hensyn viste det sig hurtigt relevant at have en liste over alle fyr i systemet, som har leveret logs, eller som har registreret sig i systemet. Man kunne også gennemgå filsystemet for at finde de fyr, som havde filer liggende, men igen ville det stride imod vores princip om at lægge semantik på filstrukturen. Derfor lavede vi det til en forudsætning, at et fyr registrerer sig med sit id (simpel string), inden det kan skrive logs eller bede om sin konfiguration. Registrationer er beskrevet med XML Schema skemaet, som er placeret i kildekoden under "xsd\registrations.xsd" og er blot en liste af furnace ids. Logisk datamodel Denne sektion beskriver den logiske datamodel, som anvendes i stokermonitor. Stokermonitor 9

10 Vi har valgt at anvende et Facade pattern til vores datamodel, så der er en klar afgrænsning mellem data (storage) delen og forretningslogikken. Dette er hensigtsmæssigt af flere årsager: Deltagerne i projektet arbejder til dels individuelt af hinanden Der kunne bruges stubbe i hele udviklingsfasen - især hvor XML skemaerne ikke var helt fastlagt Facaden For at tilgå datamodellen fra application/business niveau, skal man igennem StorageFactory, som kan levere to former for tilgange: Storage - tilgang til datamodel, som vedrører flere fyr FurnaceStorage - tilgange til datamodel, som vedrører et enkelt fyr API'et er ret simpelt og ligetil, og kommunikerer både i XML og i JAXB med klienten alt efter formålet. Implementationen Bag Storage og FurnaceStorage ligger implementationen i 3 "handler" klasser, som indkapsler de 3 hovedgrupper, LogHandler, ConfigurationHandler og RegistrationHandler. De 3 handlers instantierer hver for sig de forskellige XML api'er, de har brug for. JAXB genererede klasser bliver anvendt af implementation, facade og klientklasser. Stokermonitor 10

11 Webservices Problemstilling Et fyr i stokersystemet skal have mulighed for at logge sin status til og modtage sin konfiguration fra stokermonitor serveren. Geografisk er disse fyr placeret langt fra serveren, og det er meningen, at kommunikationen skal foregå via internettet. Teknologier Set i lyset af projektets emne, men også i kraft af at kommunikationen imellem server og fyr har karakter af RPC kald, er det naturligt at vælge en form for webservice til kommunikationen mellem disse. Vi valgte at kigge på Apache Axis2 ( da det er et meget anvendt værktøj til udvikling af webservices og det baserer sig på SOAP standarder. Afgrænsning Sikkerhed I forbindelse med kommunikation over internettet opstår der en del spørgsmål omkring sikkerhed, idet udfrakommende ikke skal have adgang til at sende falske logs eller rette konfigurationer. Vi har valgt ikke at beskræftige os med dette aspekt - opsætningen af en simpel https forbindelse kunne have løst nogle af de mest åbenlyse problemer. 2 vejs kommunikation Det ville være mere realistisk, hvis et fyr var i stand til at modtage konfigurationsændringer på serverens initiativ. Dette ville dog kræve, at fyret i sig selv kan udbyde webservices, hvilket ikke er implementeret. Det ville stort set være det samme, som skulle udføres - blot den anden vej rundt, så af hensyn til, hvad vi havde lært ved det, valgte vi at se bort fra denne del. Opbygning af webservices Når en webservice skal bygges vha. Axis 2, skal man først vælge metode at deploy'e på. Vi valgte at bruge POJOs (Plain Old Java Objects), da det forekom tilstrækkeligt til vores formål. Ideen er, at man giver Axis en POJO og en services.xml fil, som konfigurerer hvordan webservices skal udbydes. Vi lavede en klasse stokermonitor.business.stokerservice, som anvender facade interfaces fra vores datamodel til at skrive og hente de data, som er relevante. De tre dele, vi ønskede at udbyde som webservice var: Et fyr kan registrere sig på Stokermonitor serveren Et fyr kan sende en log til server Et fyr kan bede om konfiguration fra server Vi definerede en services.xml, som var som følger: <service name="stokerserverservice" scope="application"> <description> Stokermonitor 11

12 Stokermonitor server services </description> <!-- Sets up the message patterns suppported by this service --> <messagereceivers> <messagereceiver mep=" class="org.apache.axis2.rpc.receivers.rpcmessagereceiver"/> </messagereceivers> <!-- Name the POJO which is used for the service --> <parameter name="serviceclass"> stokermonitor.business.stokerserverservice </parameter> <!-- Explicitly state which message pattern is to be used by the recievelog operation. This is actually not needed, since AXIS automatically chooses in-out for operations which returns other than void --> <operation name="recievelog" mep=" /> <operation name="registerfurnace" mep=" /> <operation name="getfurnaceconfiguration" mep=" /> </service> Det mest interessante i ovenstående konfigurations fil er det Message Pattern, som ønskes anvendt. I alle tre tilfælde ønskede vi at bruge "in-out", da klienten skal kunne få besked tilbage, om operationen var gået godt. Med denne services.xml fil er Axis2 i stand til at generere en WSDL fil for vores webservice. Det næste valg er, hvorledes klienten skal genereres. Vi valgte ADB (Axis Data Binding), og fik den til - ud fra wsdl'en - at generere klienten, som skal anvende synkroniserede kald. Den genererede java klient ligger i stokermonitor.business.stokerserverservicestub. Metodesignatur for webservices De tre metoder, som udgør webservices, skulle naturligvis have en signatur. Vi valgte i de tilfælde, hvor valget var enten at sende dataholder klasser eller rå XML, at sende rå XML. Dette er i metoden recievelog(string), der som argument tager en String med en xml stump, som bør overholde XML Schema skemaet for en logentry, og i metoden getfurnaceconfiguration, som returnerer en String, som overholder XML Schema skemaet for furnace configurations. Der er følgende ulemper/fordele ved dette: Det er muligt for os at ændre XML Schema skemaerne uden at skulle ændre på webservices. Dette var en stor fordel under udviklingen Det kan blive nødvendigt at transformere fra JAXB klasser til XML og tilbage igen - f.eks. når et fyr henter konfiguration. Vi havde desværre tekniske problemer med at få ADB til at generere klienter for metoder, som anvendte JAXB klasser (som i metoden, som henter en konfiguration). Ellers havde det været en oplagt mulighed for at anvende begge metoder, men samtidig havde det krævet re-generation af klientkode ved ændringer i XML filer. Stokermonitor 12

13 Furnace simulator For at kunne afprøve webservices, udviklede vi en simulator af fyr, som - ud fra to parametre: Furnace ID og et tidsinterval i millisekunder -: 1) Registrerer sig på stokermonitor serveren med Furnace ID 2) Hver gang tidsintervallet er gået, sender den en log til serveren 3) Hver femte gang en log er sendt, beder fyret om en konfiguration fra serveren. Stokermonitor 13

14 Appendix 1: Opsætningsvejledning til prototype Prototypen er leveret som stokermonitor.zip og kræver Java SE 6 eller derover for at fungere. Systemkrav Prototypen er testet på Windows og linux, men bør kunne køre på alle platforme med Java SE6. Kræver mindst 256 mb ram og P3 eller nyere. Sådan installerer du 1. Installer Java SE 6 (hvis du ikke har den i forvejen). 2. Udpak stokermonitor.zip 3. Åbn en kommandolinje og naviger ind til "stokermonitor" mappen, hvor zippen er pakket ud. 4. Windows: Kør følgende kommando bin\tomcat6.exe Linux/unix: Kør følgende kommando java -jar bin/bootstrap.jar 5. Åbn en browser på adressen Sådan simuleres logning fra fyret Web Servicen til at logge data kan kaldes med en indbygget test-klient, som simulerer fyret ved at autogenerere data og sende dem som log. 1. Installer stokermonitor i henhold til foregående afsnit. (hvis ikke allerede gjort) 2. Åbn en browser på adressen: '1' kan udskiftes i linket til et vilkårligt furnace id, som skal være et heltal. 3. Åbn en browser på adressen 4. Naviger med venstre-menuen ind på "Furnace 1/Logs" og se den nye logning. '1' kan udskiftes til et vilkårligt furnace id, som skal være et heltal. Stokermonitor 14

15 Stokermonitor 15

16 Appendix 2: Diskussion af teknologivalg For at løse denne opgave er der blevet valgt følgende teknologier / værktøjer / metoder til at understøtte løsningen. Område Valgt Teknologi Fravalgte alternativer Programmeringssprog Java PHP, C++, C# Web Server Udvekslingsformat og Beskrivelsessprog for data Apache Tomcat XML + XML Schema JBoss, Geronimo, WebSphere Application Server, etc. DTD, Relax NG Begrundelse for valg Projektgruppen har som helhed størst kompetencer i Java. Desuden findes der en del gratis og indbyggede værktøjer i Java til understøttelse af webservices. Tomcat er gratis, let at gå til og kendes af de fleste. XML Schema er valgt da dette sprog har den bedste kombination af værktøjsunderstøttelse og udtryksfuldhed. Web Services er valgt fremfor fx. CORBA, da Web Service-teknologierne giver en mere genbrugbar løsning. Desuden opfattes det som en del af projektet at afprøve webservices i praksis. Systemgrænseflader Asynkron Web Service. SOAP, WSDL RPC, HTTP, RMI/CORBA, UDDI Asynkron kommunikation er valgt, da denne arkitektur tidsmæssigt afkobler klienter fra server, hvilket giver en større fejlrobusthed overfor forbindelsesproblemer. UDDI er fravalgt aht. simplicitet og fordi discovery samt dynamisk binding her har lav betydning. Brugergrænseflade Ext2 og JSP GWT, JSF, Servlets, Struts, etc. "Plain" JSP er den simpleste teknologi, som løser problemet. Stokermonitor 16

17 Persistering og forespørgsler XML i server-filsystem, XPATH. RDBMS, SQL, XML-database Datakonvertering XSLT Håndkodet Sikkerhedsmodel Basic HTTP autentificering og rollebaseret, deklarativ sikkerhed med JAAS og Servlet API. Form-based autentificering. Programmatisk sikkerhed. XML persistering i FS er valgt da det er det simpleste og mest gennemskuelige at udvikle med. Dette projekts fokus er på XML- og Web-teknologier - ikke high-performance persistering, som SQL RDBMS og ORM kan give. Derfor er den ekstra kompleksitet i et RDBMS fravalgt. Basic auth. er valgt aht. simplicitet. Rollebaseret, deklarativ sikkerhed er anvendt fremfor programmatisk sikkerhed da eksternalisering af sikkerhedshensyn fra program-koden giver et mere solidt og vedligeholdbart sikkerhedssystem. Stokermonitor 17

18 Appendix 3: Installation af Axis2 Installering af Apache Axis2 Web services engine på Tomcat server. Det er en forudsætning, at der er en Tomcat server installation tilgængelig, hvorpå at Axis2 kan installeres. 1. Download axis2-1.3-bin.zip fra list 2. Unzip filen axis2-1.3-bin.zip 3. Unzip filen axis2-1.3-war.zip (indeholdt i axis2-1.3-bin.zip) 4. Kopier filen axis2.war til../webapps folder i Tomcat installation. Hvis Tomat serveren kører vil axis2.war filen pakke sig selv ud automatisk. 5. Nu er web serveren faktisk klar til at få installeret web services. Installering og test af en web service. 1. kompiler nedenstående java klasse. (StockQuoteService class) package samples.quickstart.service.pojo; import java.util.hashmap; public class StockQuoteService { private HashMap map = new HashMap(); public double getprice(string symbol) { Double price = (Double) map.get(symbol); if(price!= null){ return price.doublevalue(); } return 42.00; } } public void update(string symbol, double price) { } map.put(symbol, new Double(price)); 2. Opret en folder struktur under \..\webapps\axis2\web-inf\services\, der ser således ud: StockQuoteService\samples\quickstart\service\pojo og placer StockQuoteService class i folderen pojo. 3. Opret en folder under: StockQuoteService, der skal hedde: META-INF 4. I folderen: META-INF placer en fil, som skal hedde services.xml. services.xml skal have nedenstående indhold: <service name="stockquoteservice" scope="application"> <description> Stock Quote Sample Service </description> Stokermonitor 18

19 <messagereceivers> <messagereceiver mep=" class="org.apache.axis2.rpc.receivers.rpcinonlymessagereceiver"/> <messagereceiver mep=" class="org.apache.axis2.rpc.receivers.rpcmessagereceiver"/> </messagereceivers> <parameter name="serviceclass"> samples.quickstart.service.pojo.stockquoteservice </parameter> </service> 5. Lav en reload af axis2 og servicen er klar til at blive kaldt. manager/reload?path=/axis2 6. Denne URL kan kaldes for at teste om servicen virker: services/stockquoteservice/getprice?symbol=ibm 7. Som retur fra web serveren skulle gerne komme nedenstående XML <ns<ns:getpriceresponse xmlns:ns=" <ns:return>42.0</ns:return> </ns:getpriceresponse Stokermonitor 19