Utvärdering av protokollet SOAP

Utvärdering av protokollet SOAP Är SOAP framtidens kommunikationsprotokoll i distribuerade datorsystem över Internet? Evaluation of the SOAP protocol Is SOAP the future communication protocol in distributed computer systems over the Internet? Examensarbete inom datalogi av Magnus Hanno Stockholm 12 februari 2002 Examinator: Stefan Arnborg Kungliga Tekniska Högskolan Handledare: Per Svensson Kungliga Tekniska Högskolan Handledare: Mats Larsson Agero Creation AB Institutionen för Numerisk analys och datalogi vid Kungliga Tekniska Högskolan

Utvärdering av protokollet SOAP 3 Sammanfattning Denna rapport beskriver ett examensarbete om Simple Object Access Protocol (SOAP). Examensarbetet som utfördes på uppdrag av Agero Creation AB gick dels ut på att studera SOAP, dels att testa implementeringar av SOAP samt att med hjälp av SOAP skapa ett WAP-gränssnitt till ett tidrapporteringssystem. SOAP är ett kommunikationsprotokoll baserat på XML som ska underlätta kommunikationen mellan applikationer som är skrivna i olika programmeringsspråk och placerade på olika plattformar. Studien av SOAP gjordes framförallt med hjälp av litteraturstudier, men även vid testningen av SOAP-verktyg framkom intressanta aspekter av SOAP. Att SOAP är ett nytt protokoll visade sig bland annat när alla SOAP-verktyg inte var kompatibla med varandra. Implementeringen gjordes för att testa det som kommit fram under studien av SOAP samt vid testerna av SOAP-verktyg. Det som skulle göras vid implementeringen var att skapa ett WAP-gränssnitt till ett tidrapporteringssystem. WAP-gränssnittet skulle använda befintligt tidrapporteringssystems logik via SOAP. I rapporten har jag kommit fram till att SOAP är ett kommunikationsprotokoll som kommer att få en stark ställning. Det kommer däremot att ta några år innan SOAP får denna ställning, framför allt på grund av att det tar tid att etablera ett nytt protokoll. De SOAP-verktyg som finns nu (juni 2001) är bra men jag är säker på att det kommer komma bättre ju mer SOAP används. Nuvarande SOAP-verktyg har vissa barnsjukdomar. Implementeringen gjordes utan problem, men mycket arbete återstår för att tidrapportering ska kunna ske via ett WAP-gränssnitt.

Utvärdering av protokollet SOAP 5 Abstract Evaluation of the SOAP protocol Is SOAP the future communication protocol in distributed computer systems over the Internet? This report describes a master thesis project about Simple Object Access Protocol (SOAP). The master thesis project was commissioned by Agero Creation AB and consists of three parts; study of SOAP, testing of the SOAP toolkits and implementation of a WAP interface to a time-reporting system. SOAP is a communication protocol based on XML, which is supposed to simplify communication between applications written in different programming languages and placed on different platforms. The SOAP study was performed mainly by reading articles. However, by the testing of SOAP toolkits some interesting aspects of SOAP came to light. SOAP is a new communication protocol and it became obvious when some of the SOAP toolkits where incompatible. The implementation was made to test the information gathered during the study of SOAP and the testing of the SOAP toolkits. The aim of the implementation was to create a WAP interface for a time-reporting system. The WAP interface was supposed to use the existing time-reporting systems logic via SOAP. My conclusion in this report is that SOAP will become a leading communication protocol. However, it will take some time until SOAP gets this position as it takes time to establish a new protocol. The SOAP toolkits of today (June 2001) are good but they have some flaws and I believe that better toolkits will emerge when SOAP has become more widely used. The implementation was performed without any problems, but a lot of work remains until the WAP interface to the time-reporting system is finished.

Utvärdering av protokollet SOAP 7 Innehållsförteckning 1 INLEDNING...9 1.1 BAKGRUND...9 1.2 DISTRIBUERAD SYSTEMUTVECKLING...9 1.3 AGERO CREATION AB...10 2 PROBLEMSTÄLLNING...11 2.1 PROBLEM...11 2.2 MÅL...11 2.3 METOD...11 3 DISTRIBUERADE OBJEKTTEKNOLOGIER...13 3.1 CORBA...13 3.2 DCOM...14 3.3 JAVA RMI...14 3.4 ANLEDNINGAR TILL ATT INGEN AV DESSA BLIVIT EN INTERNETSTANDARD...15 4 SOAP...17 4.1 XML...17 4.2 SOAPS UPPBYGGNAD...18 4.3 SOAP OCH TRANSPORTPROTOKOLL...21 4.4 RPC MED HJÄLP AV SOAP...21 4.5 SOAPS FÖR- OCH NACKDELAR...23 4.6 SOAP SOM KOMMUNIKATIONSPROTOKOLL...24 4.7 WEBBTJÄNSTER...27 4.8 SAMMANFATTNING...31 5 SOAP-VERKTYG...33 5.1 GLUE...33 5.2 SOAP4J...34 5.3 MS SOAP TOOLKIT 2.0...35 5.4 PROBLEM MED KOMMUNIKATIONEN...35 6 IMPLEMENTATIONEN...37 6.1 BEFINTLIGT SYSTEM...37 6.2 WAP...37 6.3 BEGRÄNSNINGAR...38 6.4 DET NYA SYSTEMET...39 6.5 UTVECKLINGSARBETET...40 6.6 SAKER SOM ÅTERSTÅR ATT LÖSA...42 6.7 SAMMANFATTNING...42

Utvärdering av protokollet SOAP 8 7 REKOMMENDATION...43 8 LITTERATURFÖRTECKNING...44 9 BILAGOR...47 9.1 ORDLISTA...47

Utvärdering av protokollet SOAP 9 1 Inledning Denna rapport sammanfattar ett examensarbete på institutionen för Numerisk Analys och Datalogi (Nada), KTH. Arbetet genomfördes under våren och sommaren 2001 och är en del av civilingenjörsutbildningen i datateknik på KTH. Uppdragsgivare var systemutvecklingsföretaget Agero Creation AB i Stockholm. 1.1 Bakgrund Agero Creation AB är ett systemutvecklingsföretag som bygger och utvecklar skräddarsydda informationslösningar för stora företag. Arbetet bedrivs på konsultbasis och de anställda rapporterar in arbetad tid i ett tidrapporteringssystem. Då de anställda börjat uttrycka önskemål att kunna tidrapportera på fler sätt än via webben och då framför allt via en WAPklient har frågan uppstått hur ett sådant WAP-gränssnitt skulle utvecklas. Önskvärt vore om de befintliga komponenterna i det webbaserade tidrapporteringssystemet skulle kunna användas även till WAP-gränssnittet. Vidare vore det bra om systemet utvecklades på ett sådant sätt att ytterligare gränssnitt t.ex. talsvar skulle kunna läggas till utan betydande ändringar av befintliga komponenter. Tanken som kom upp var att ett distribuerat system skulle utvecklas. Klienterna i systemet skulle vara gränssnitt t.ex. ett WAP-gränssnitt eller webbgränssnitt och servern skulle tillhandahålla den grundläggande logiken och databasen. Det var i detta läge som detta examensarbete kom in i bilden. Uppgiften var att undersöka hur det ovan beskriva systemet skulle kunna utvecklas samt att utvärdera det nya kommunikationsprotokollet Simple Object Access Protocol (SOAP). Slutligen skulle ett WAP-gränssnitt till delar av tidrapporteringsystemet utvecklas med hjälp av SOAP. 1.2 Distribuerad systemutveckling Betydelsen av nätverk i datorsystem har de senaste tio åren ökat enormt, speciellt sedan intresset för Internet spreds bland gemene man. Datorer måste ha möjligheten att kommunicera med varandra på ett effektivt sätt och det är där utveckling av distribuerade system kommer in i bilden. Ett system sägs vara distribuerat om datorprogram och data som bearbetas är spridda över mer än en dator, oftast via ett nätverk. Det är viktigt att komma ihåg att distribuerade applikationer fordrar en helt ny sorts design och för att den ökade komplexiteten ska vara mödan värd måste det finnas några fördelar. Vissa system är distribuerade i sin natur, till exempel telefonsystem och spel med flera användare. I dessa fall är det uppenbart att de måste vara distribuerade. Men även andra system kan med fördel vara distribuerade. De största fördelarna med distribuerade applikationer är att de skapar en ökad flexibilitet att avgöra var olika delar av applikationen

Utvärdering av protokollet SOAP 10 ska köras. Applikationen blir också mer skalbar. Om all logik ligger på en dator måste hårdvaran uppgraderas om man vill få bättre prestanda eller bara upprätthålla nuvarande prestanda vid ökande arbetsbörda. Är däremot applikationen utvecklad med distribuerad design behöver servern som komponenterna körs på bara flytta över en del arbete till en annan dator för att upprätthålla eller öka prestandan. 1.3 Agero Creation AB Agero Creation AB bygger och utvecklar skräddarsydda informationslösningar för stora företag. De anställda på Agero Creation har en gedigen teknisk utbildning och tillsammans besitter de mångåriga kunskaper om tekniska system och deras möjligheter. Agero Creation har lång erfarenhet av Microsofts utvecklingsmiljöer. De har på senare tid jobbat mycket med Java och RUP, och har under årens lopp arbetat med många förkortningar i datavärlden: UNIX, ASP, JSP, WAP, COM, DCOM, VB, EJB, C++, MTS och IIS. Agero Creation är ett bolag i Agerogruppen. Agero Creation har idag ett 40-tal medarbetare och hela gruppen består av cirka 50 medarbetare. Det andra bolaget i gruppen är Agero Business Consulting.

Utvärdering av protokollet SOAP 11 2 Problemställning De problem och mål som detta examensarbete kommer att behandla beskrivs kortfattat nedan: 2.1 Problem 2.2 Mål 2.3 Metod Två problemområden behandlas i detta examensarbete. Är SOAP den kommande standarden för distribuerade system över Internet? Distribuerade system är inget nytt. Däremot har ingen av föregångarna till SOAP lyckats bli en Internetstandard. Frågan är nu om SOAP, som är uppbyggt av Internetstandarder, kan bli det kommunikationsprotokoll som blir standarden för distribuerade system över Internet. Är SOAP och de SOAP-verktyg som finns användbara i Ageros fall? Agero vill skapa ett WAP-gränssnitt till sitt tidrapporteringssystem. Frågan är om SOAP är lämpligt att använda för detta. För att få ett svar på de två ovan nämnda problemen har tre mål satts upp för detta examensarbete. Målen är att åstadkomma: en studie av SOAP, en undersökning av de SOAP-verktyg som finns på marknaden, en implementation av ett WAP-gränssnitt till det befintliga tidrapporteringssystemet med hjälp av SOAP. För att uppnå de tre målen med detta examensarbete delades arbetet upp i flera delar. Det första målet, att studera SOAP, handlade till stor del om informationsinsamling. De två andra var däremot mer av praktisk karaktär. De moment som arbetet delades upp i var följande: 1. Informationsinsamling 2. Analys 3. Test av SOAP-verktyg 4. Utvärdering 5. Planering av implementation 6. Test av grundidén 7. Implementation 8. Rapportskrivande

Utvärdering av protokollet SOAP 12 Det första momentet (1) gick ut på att samla information om protokollet SOAP och andra distribuerade protokoll. Målet med informationsinsamlandet var att få en så bred kunskap om SOAP som möjligt. I nästa moment (2) analyserades materialet. Vad är tanken med SOAP, vad är det tänkt att det ska gå att göra med hjälp av protokollet SOAP, hur står det sig mot andra protokoll och har SOAP möjlighet att bli en Internetstandard? Svaren på de här frågorna finns i kapitel 4 SOAP. Efter utvärderingen av SOAP testades tre SOAP-verktyg (3). Det som undersöktes var bland annat hur lätta de var att använda, vad de klarar och om de är kompatibla med varandra. Detta följdes av en utvärdering (4). I kapitel 5 SOAP-verktyg beskrivs och utvärderas de testade SOAP-verktygen. Med kunskap om SOAP och verktyg som implementerar SOAP gjordes en grundlig planering av implementeringen (5). Vad exakt som skulle göras och lösningsförslag utarbetades. När ett lösningsförslag fastställts, genomfördes en del implementeringsarbete för att testa (6) och säkerställa att alla leden i det nya systemet fungerade. Detta följdes av viss implementering av funktioner till det nya systemet (7). Hur implementeringen gick kan läsas om i kapitel 6 Implementationen. Avslutningsvis sammanställdes allt som kommit fram under arbetet (8).

Utvärdering av protokollet SOAP 13 3 Distribuerade objektteknologier Det finns ett flertal olika protokoll för distribuerade objektsystem. De fyra som tas upp i detta examensarbete är CORBA, DCOM, Java RMI och SOAP. CORBA, DCOM och Java RMI tas kort upp i detta kapitel. Meningen är inte att läsaren ska få en heltäckande kunskap om de tre teknologierna utan få en kort introduktion. Denna introduktion ska ge läsaren tillräcklig kunskap för att förstå anledningarna till att ingen av dessa tre teknologier blivit en Internetstandard. Dessa tas upp under rubriken 3.4 Anledningar till att ingen av dessa blivit en Internetstandard. 3.1 CORBA The Object Management Group (OMG) har tagit fram Common Object Request Broker Architecture (CORBA). CORBA är en standard för distribuerad objektorientering. OMG består av drygt 800 företag och OMGs uppgift är att diskutera framtida versioner av objektorientering och framför allt distribuerad objektorientering och CORBA [14]. ORB är kärnan av CORBA och den fungerar som en buss. Objekt kan använda ORBen för att kommunicera med andra objekt oberoende av om de ligger lokalt eller ej. Det övergripande målet med CORBA är att applikationer ska kunna kommunicera med varandra oavsett var de är placerade och hur de är implementerade [14]. 3.1.1 Metodanrop ORB är det objekt som etablerar kontakten mellan en klient och en server. Genom att använda en ORB kan en klient aktivera en metod på en server. ORBen ser till att paketera metodanropet med dess parametrar och att lokalisera servern där metoden finns (information om metoden finns hos en på klienten placerad procedurstomme (eng. stub), vilken fungerar som ett gränssnitt mot metoden). Servern kan antingen ligga lokalt eller på samma nätverk. På servern är ORBen ansvarig för att ta emot anropet, aktivera metoden och returnera resultatet. Klienten behöver inte veta var metoden fysiskt är placerad, dess programmeringsspråk, operativsystem eller några andra aspekter av systemet [14]. Tanken med CORBA är att standarden ska vara oberoende av operativsystem. Det har dock visat sig att CORBA fungerar bäst under UNIX [1]. Både det binära kommunikationsformatet Common Data Representation (CDR) och adresseringsformatet Interoperable Object Reference (IOR) är specifika för CORBA. Med hjälp av IOR kan alla CORBA-produkter avgöra var en metod är placerad och CDR är det format all kommunikation sker med.

Utvärdering av protokollet SOAP 14 CORBAs kommunikationsprotokoll heter General Inter-ORB Protocol (GIOP). TCP/IP versionen av GIOP heter Internet Inter-ORB Protocol (IIOP). GIOP specificerar ett antal meddelanden som ORBar kan skicka mellan sig. Ett meddelande innehåller information såsom storlek, typ, version och bitordning på meddelandet [14]. 3.2 DCOM Component Object Model (COM) är en standard som gör det möjligt för objekt att tillhandahålla tjänster till andra objekt. Standarden togs fram av Microsoft när de utvecklade operativsystemet Windows 3.0. Problemet med COM var att objekten var tvungna att ligga på samma dator för att kunna användas. Detta löste Microsoft genom att utveckla Distributed COM (DCOM). DCOM kan lokalisera objekt oberoende av om de ligger lokalt eller på nätverket. DCOM är den mest komplexa distribuerade objektteknologin som tas upp i detta examensarbete [9]. 3.2.1 Metodanrop Metodanrop till ett via nätverk åtkomstbart objekt (metod) sker via ett ombud (eng. proxy). Ombudet ligger lokalt på en klient och objektet finns på en server. Vid ett metodanrop behöver ombudet en referens till objektet. Service Control Manager (SCM) etablerar kontakten mellan en klient och en server. Med hjälp av SCM får klienten möjlighet att skapa en instans av det via nätverket åtkomstbara objektet. Klientens SCM tar kontakt med serverns SCM. SCM på servern aktiverar då objektet och skickar tillbaka en referens. Det på klienten liggande ombudet kan sedan skapa en instans av objekt på servern. Efter detta kommer klienten att ha direktkontakt med det på servern placerade objektet via ombudet. DCOM är en Microsoft-standard och fungerar därför bäst under operativsystemet Windows [1]. Både det binära kommunikationsformatet Network Data Representation (NDR) och adresseringsformatet OBJREF är specifika för DCOM. Med hjälp av OBJREF håller DCOM reda på var en metod är placerad och NDR är det format all kommunikation sker med [9]. DCOMs kommunikationsprotokoll heter Object Remote Procedure Call (ORPC). ORPC består av flera olika paket som ORPC kan skicka mellan sig. Paketen innehåller information såsom objektets id-nummer, flaggor, räknare och säkerhetsinformation [9]. 3.3 Java RMI Java Remote Method Invocation (Java RMI) är, som namnet avslöjar, en Javabaserad distribuerad objektteknologi. RMI tillhandahåller en enkel modell för distribuerad

Utvärdering av protokollet SOAP 15 systemutveckling med Java. Idén med RMI är att Javaobjekten efter implementation ska kunna köras var som helst och överallt, d.v.s. objektet ska kunna anropas oberoende av operativsystem där objektet är placerat och var objektet fysiskt är placerat, lokalt eller åtkomligt via ett nätverk [10]. 3.3.1 Metodanrop Det första en Javaklient gör vid ett metodanrop är att fråga ett register i RMI var metoden är placerad. Med hjälp av adressen kan sedan RMIn hämta en procedurstomme som klienten använder för att anropa metoden via nätverket. Det som gör RMI unikt jämfört med CORBA och DCOM är att procedurstommen kan hämtas vid anropet. CORBA och DCOM kräver att procedurstommen (eller ombud i DCOM) finns lokalt före anropet [10]. Java RMI Wire-Protocol (JRMP) är RMIs kommunikationsprotokoll. Det är ett relativt enkelt protokoll som består av tio olika meddelanden. JRMP paket består av en header följt av ett eller fler meddelanden. Headern består av ASCII koden för JRMI, versionsnummer och vilket underprotokoll som ska användas. Det finns totalt tre underprotokoll: SingleOpProtocol, StreamProtocol och MultiplexProtocol. SingleOpProtocol anger att headern följs av ett enstaka meddelande och att förbindelsen kan brytas efter att meddelandet skickats. StreamProtocol och MultiplexProtocol anger att headern följs av ett eller fler meddelanden och att förbindelsen mellan klient och server ska upprätthållas [10]. All information som JRMP förmedlar paketeras enligt Javas Object Serialization Protocol som är specifikt för Java. RMI kan använda HTTP som transportprotokoll [10]. 3.4 Anledningar till att ingen av dessa blivit en Internetstandard Ett grundläggande krav för att en distribuerad objektteknologi (protokoll) ska bli en standard är att det ska vara möjligt att använda protokollet oberoende av vilken plattform som används. Vidare måste protokollet vara implementerat på ett sådant sätt att oberoende vilken plattform protokollet är implementerat på ska det vara möjligt att kommunicera med andra plattformars implementeringar. T.ex. ska Windows- och UNIX-versionerna fungera tillsammans utan problem. Dessutom måste det vara möjligt att använda protokollet oberoende av programmeringsspråk. För att det ska kunna bli en Internetstandard krävs även att kommunikationen kan ske över Internet. Ett problem som kan uppstå med detta är brandväggar. De flesta nätverk har någon sorts brandvägg som stoppar kommunikationen på alla portar utan vissa förbestämda, t.ex. port 80 för HTTP. En del protokoll (t.ex. CORBA) använder sig däremot av dynamisk tilldelning av vilken port som ska användas och kommer att stoppas av brandväggen om inte den porten är öppen [1].

Utvärdering av protokollet SOAP 16 Hur klarar då CORBA, DCOM och Java RMI detta? Inte särskilt bra och anledningarna till detta tas upp nedan. Trots att många tillverkare av CORBA- och DCOM-baserade mjukvaror anser att de täckt in ett flertal operativsystem fungerar det inte tillfredsställande när en CORBA implementering körs på ett Windows-system eller DCOM på ett UNIX-system [1]. DCOM är framtaget av Microsoft och fungerar därför bäst på ett Windows-system och CORBA är konstruerat på ett sånt sätt att det lämpar sig bäst på ett UNIX-system. Java RMI fungerar däremot utan problem på olika operativsystem men då måste all implementering ske i Java och oberoendet av programmeringsspråk faller. Inte heller fungerar CORBA, DCOM eller Java RMI tillsammans, främst beroende på att de har olika sätt att ange adresser och paketera metodanrop. CORBA har IOR och CDR, DCOM OBJREF och NDR och Java RMI JRMP. Slutligen är det inte något av protokollen som på ett tillfredsställande sätt klarar brandväggar, vilket man kan kräva av ett protokoll som ska användas över Internet.

Utvärdering av protokollet SOAP 17 4 SOAP Simple Object Access Protocol (SOAP) är ett kommunikationsprotokoll baserat på XML som ska underlätta kommunikationen mellan applikationer som är skrivna i olika programmeringsspråk och placerade på olika plattformar. Den första versionen av protokollet utarbetades av utvecklare på DevelopMentor, Microsoft och Userland software. SOAP 1.1 som när detta skrevs var den senaste versionen av SOAP har lämnats in till World Wide Web Consortium (W3C) [17]. W3C ska avgöra om SOAP ska bli en Internetstandard. Tidigare erfarenheter av de protokoll som blivit Internetstandarder (HTTP, TCP/IP) är att de varit de enklaste protokollen som fått arbetet gjort [1]. SOAP definierar inte någon programmeringsmodell eller specifik implementationssemantik utan tillhandahåller en modell för hur meddelanden ska paketeras och data kodas. Detta gör att SOAP kan användas i olika system från meddelandesystem till RPC-system 1 [17]. Huvudmålet med SOAP är att det skall vara enkelt och utbyggbart. Detta har lett till att fler finesser, som andra distribuerade objektteknologier har, inte finns med i SOAPspecifikationen. Sådana finesser är [15]: Distribuerad automatisk minneshantering (eng. garbage collection), Referenser till objekt, Funktioner som kräver de ovan nämnda finesserna. 4.1 XML Innan SOAP beskrivs ingående är det på sin plats att först ta upp XML. Detta för att läsaren lättare ska förstå SOAP och dess uppbyggnad. XML är ett standardiserat sätt att representera data på ett strukturerat sätt. Vidare är XML en Internetstandard som fått ett stort genomslag inom Internetapplikationer. Anledningar till att XML blivit så framgångsrikt är att det är enkelt, det är textbaserat och det är ett utvecklingsbart språk. Vidare är det mycket praktiskt att spara data som ska presenteras på en webbsida i XML. Detta på grund av att ingen datamanipulation måste föregå presentationen [4]. Två grundläggande begrepp inom XML är namndomäner och XML-scheman. Dessa är också av stor vikt inom SOAP. 1 RPC står för Remote Procedure Call. I ett RPC-system kan metoder anropas via ett nätverk.

Utvärdering av protokollet SOAP 18 4.1.1 Namndomän I XML har namndomäner (eng. namespace) till uppgift att skilja på element/attribut som har samma namn. I en organisation kan det t.ex. finnas XML-dokument med information som har samma namn. T.ex. kan titel såväl beskriva en position inom organisationen som titeln på en bok. För att skilja på dessa finns namndomäner som anger vilken information som gäller [15]. 4.1.2 XML-schema Ett XML-schema är ett XML-dokument som anger hur ett specifikt XML-dokument ska byggas upp, t.ex. vilka element/attribut som ska ingå och deras placering. Vidare kan schemat specificera vilka datatyper dessa element ska ha. Syftet med att använda XMLscheman är att kunna kontrollera om ett XML-dokument är giltigt, med avseende på schemat. Denna kontroll utförs av en XML-parser. En parser används för att tolka/översätta ett XML-dokument åt en applikation [15]. 4.1.3 XML via HTTP Det finns flera förslag på att använda XML i RPC-anrop via HTTP. Gemensamt för dessa är att de alla använder ett litet antal HTTP-headers och XML för att anropa metoder över ett nätverk. I XML-dokumentet finns information om metoden och dess parametrar. Svarsmeddelandet på ett anrop har även det en fördefinierad XML-struktur. Det finns ungefär femton olika förslag på protokoll som använder XML vid RPC-anrop. Fler av dessa protokoll beskrivs av W3C på deras webbplats [21]. Några av dessa protokoll är XML-RPC, SOAP, WDDX och ebxml. Trots att alla dessa protokoll skulle kunna bli en Internetstandard är det SOAP som fått störst genomslag. En stor anledning till att RPC-anrop med hjälp av XML via HTTP blivit en så stor framgång är XMLs spridning. Ett problem med metodanrop över distribuerade system är namnkollision. Olika metoder kan ha samma namn och dessa måste skiljas åt. Detta har lösts i XML (som nämnts ovan) med namndomäner. Namndomäner kan även användas för att undvika namnkollision vid distribuerade metodanrop. Ett metodnamn blir därmed otvetydigt. SOAP definierar två namndomäner. 4.2 SOAPs uppbyggnad SOAP-meddelanden är i grunden envägskommunikation från sändare till mottagare. SOAPmeddelanden kan dock kombineras för att implementera mönster som förfrågan/svar (eng.

Utvärdering av protokollet SOAP 19 request/response) i t.ex. RPC-anrop [17]. Mer om detta under kapitel 4.4 RPC med hjälp av SOAP. Nedan visas ett exempel på ett SOAP-meddelande. Ett sådant har tre delar: ett obligatoriskt Envelope-element, ett frivilligt Header-element och ett obligatoriskt Body-element. <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Header> <From SOAP:mustUnderstand= 1 > sender@somebody.com </From> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>def</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 4.2.1 SOAP Envelope XML-elementet Envelope måste vara det första elementet i ett SOAP-meddelande. Detta element indikerar att aktuellt XML-dokument är ett SOAP-meddelande och inkapslar övriga delar av meddelandet. I Envelope anges även vilken namndomän som ska användas. Namndomänen för Envelope är: http://schemas.xmlsoap.org/soap/envelope/ [17]. Om en felaktig namndomän anges ska en SOAP-applikation ignorera SOAP-meddelandet. 4.2.1.1 Avkodningsregler Avkodningsregler används för att serialisera data i SOAP-meddelanden. Reglerna används även av applikationen som tar emot meddelandet för att återskapa datat. Attributet encodingstyle i elementet Envelope används för att ange de avkodningsregler som ska användas i meddelandet. Värdet på attributet är en URI som identifierar adressen till avkodningsreglerna. URIen till SOAPs avkodningsregler är: http://schemas.xmlsoap.org/ soap/encoding/ [17]. 4.2.2 SOAP Header Om ett Header-element ingår i SOAP-meddelandet skall det följa direkt under Envelopeelementet. Detta element kan innehålla extra information som hjälper till vid t.ex. kryptering, transaktionshantering eller behörighetskontroll. Även applikationsspecifik data kan placeras i Header.

Utvärdering av protokollet SOAP 20 4.2.2.1 Header-attribut I Header-element finns två fördefinierade Header-attribut, mustunderstand och soapactor. MustUnderStand-attributet används för att ange om mottagaren av meddelandet måste behandla Header-elementet eller om detta är valfritt. Att utelämna mustunderstand-attributet anger att det är valfritt att behandla Headern. SoapActor-attributet anger vilken mottagare som Header-elementet är avsett för. Värdet på soapactor-attributet är en URI, som motsvarar adressen till avsedd mottagare. Att utelämna soapactor-attributet betyder att den slutliga mottagaren av SOAP-meddelandet är den avsedda mottagaren för Header-elementet [17]. 4.2.3 SOAP Body I SOAP Body finns själva informationen av meddelandet. I Body är all data som applikationerna utväxlar placerad. Det kan vara ett RPC-metodanrop eller någon annan sorts informationsutväxling mellan applikationer. Body-elementet återfinns som första element efter Envelope-elementet, såvida inget Header-element ingår för då följer Body-elementet Headern. Body-elementet består av Body Entries. Dessa element kan vara godtyckliga, egendefinierade XML-element. SOAP definierar en Body Entry vid namn Fault, som används för felhantering. 4.2.4 SOAP Fault Fault-elementet används för felhantering. Ett SOAP Fault-element måste förekomma som ett SOAP Body-element och får inte förekomma fler än en gång i ett meddelande. Ett SOAP Fault-element består av fyra underelement [17]: Faultcode. Används för att identifiera vilken typ av fel som uppstått. Faultcode måste finnas i ett SOAP Fault-element och specifikationen SOAP definierar ett litet antal faultcodes som täcker in några grundläggande fel. Faultcode är framför allt tänkt att användas av applikationer. Faultstring. En beskrivning av felet som inte är tänkt att användas av applikationer. Faultstring måste finnas i ett SOAP Fault-element och bör beskriva felet på ett sådant sätt att orsaken till felet kan fastställas. Faultactor. Ska ge information om var felet uppstod. Värdet av Faultactor-attributet är en URI som identifierar källan. Detail. Tillhandahåller applikationsspecifik felinformation relaterad till informationen i Body-elementet. Detail måste finnas med i Fault-elementet om informationen i Bodyn inte bearbetas framgångsrikt. Fel i Headern tas inte upp i Detail utan dessa fel tas upp i Headern. Om Detail elementet inte finns med i ett SOAP Fault-element betyder det att felet inte är relaterat till bearbetningen av informationen i Bodyelementet.

Utvärdering av protokollet SOAP 21 4.2.5 SOAP Encoding SOAPs avkodningsregler baseras på ett enkelt typsystem, liknande det som finns i programmeringsspråk. XML tillåter en mycket flexibel avkodning av data medan SOAP definierar hårdare regler vid avkodning. SOAPs typsystem är kompatibelt med XML Schema Definition Language (XSD). En typ i SOAP kan antingen vara enkel/skalär eller sammansatt av flera delar som i sin tur är av godtycklig typ [17]. 4.2.5.1 Enkla typer SOAP tillåter och använder de enkla typer som definieras som inbyggda datatyper för XMLscheman. Exempel på sådana typer är heltal, decimaltal och strängar. Dessa typer kan användas direkt i element-scheman. Även typer som byggs upp av dessa enkla typer kan användas. 4.2.5.2 Sammansatta typer De sammansatta datatyperna är mer komplexa datastrukturer, såsom vektorer. Ett exempel på en komplex datastruktur kan vara en produkt som består av ett namn, ett produktnummer samt ett pris. Den här informationen kan definiera en sammansatt typ. Sammansatta typer kan även ha element som består av sammansatta typer och så vidare. 4.3 SOAP och transportprotokoll SOAP-specifikationen specificerar inte vilket transportprotokoll som ska användas vid kommunikationen mellan två applikationer. Enligt specifikationen kan SOAP kopplas till olika transportprotokoll, såsom HTTP, SMTP och FTP. Däremot beskrivs bara kopplingen till HTTP i specifikationen av SOAP 1.1. Vidare klarar de implementeringar som gjorts av SOAP bara HTTP (juni 2001). En stor fördel med att SOAP kan använda sig av HTTP som transportprotokoll är att SOAP i och med detta fungerar utmärkt i system med brandväggar. En brandvägg släpper bara igenom trafik på vissa förbestämda portar, t.ex. HTTP-trafik på port 80. Detta gör att när SOAP använder sig av HTTP fungerar SOAP utan problem med en brandvägg [17]. 4.4 RPC med hjälp av SOAP Ett av målen med SOAP-specifikationen är att genomföra RPC-anrop. I det fall SOAP kopplas till HTTP görs ett RPC-anrop med hjälp av en HTTP-förfrågan och RPC-svaret levereras med ett HTTP-svar meddelande. Det ska däremot påpekas att SOAP RPC-anrop