Web Services. 1. Vad är Web Services?

Web Services Magnus Söderström Department of Computer Science Åbo Akademi University, FIN-20520 Åbo, Finland e-mail: masoders@abo.fi URL: http://www.abo.fi/~masoders Abstrakt Web Service är ett försök att standardisera RPC metoden som förut varit beroende av plattform och språk, allt från CORBA till RMI och bygger på redan tillgängliga och standardiserade byggstenar nämligen XML och HTTP. Web Service kan delas upp i tre olika delar, SOAP protokollet vilket definierar vad som flyttas. WSDL beskriver hur data handlas och till sist UDDI som berättar vilka services som finns tillgängliga. Web Service är en plattform oberoende metod att transportera och söka data från geografiskt distribuerade system. Klassificering C.2.2, C2.4, C.2.6, I.7.2, SIGecom, SIGIR 1. Vad är Web Services? Web Services är ett brett begrepp som kan definieras på många olika sätt. Bland annat har Web Services definierats som...a network-accessible interface to application functionality, built using standard Internet technologies eller...any service that is available over the Internet, uses a standardized XML messaging system, and is not tied to any one operating system [TilleyEtAl02]. Det centrala delarna i definitionerna ovan är nätverk, plattform oberoende samt XML. Web Services kan sägas på ett sätt revolutionera det sätt vi ser applikations funktionalitet. Den gör

det genom att möjliggöra funktionsanrop över nätet oberoende av sändarens och mottagarens teknik, om det sen är det lokala nätet eller över internet. I och med att Web Services tekniken fungerar runt XML och HTTP som är standarder så betyder det att man samtidigt uppnår plattform oberoende som är problemet med bla. RMI, CORBA, RPC and andra liknande teknologier. Dessa är oftast bundna till en viss plattform eller leverantör vilket binder en till en viss teknologi vilket inte alltid är önskvärt. Web Services är en 4-5 år gammal teknik som kom i början av 1999 av adopterades snabbt av Microsoft [ElPaLu02]. Ett par år senare kom IBM med en liknande specifikation som lämnade in till W3C konsortiet som om ut med en standard runt vilket tekniken nu kan användas. Trots att de centrala delarna i Web Services har standardiserats så som SOAP (Simple Object Access Protocol), WSDL (Web Services Definition Language) och UDDI (Universal Description, Discovery and Integration) så finns det en hel del ny teknik som fortsätter där de ovan givna teknikerna slutar. Dessa tekniker (så som WSFL (Web Services Flow Language)) tävlar nu om en plats i solen för att kanske inom sitt område bli en standard [AMS02, Sta03]. Web Services kan komma att revolutionera sättet på hur vi i en snar framtid ser, kör och anropar distribuerade objekt samt hur kod kan modulariseras samt återanvändas effektivt. Just genom att Web Services är återanvändbara, öppna, plattform oberoende och baserar sig på redan existerande standarder så har de en mycket bra chans att bli framgångsrika. Genom texten kommer det att antas att läsaren har en insikt om XML samt hur XML fungerar. 2. Web Services en översikt WS kan delas in i tre olika områden: 1. Web Services 2. Service klienten 3. UDDI registret

UDDI WSDL WSDL Client XML/SOAP/HTTP Bild 1. Web Service översikt [Va-Ni02, RoRa01] Web Service WS definierar sina funktioner samt data typer ett dokument via WSDL (Web Services Definition Language) som är en vanlig XML fil. WSDL dokumentet registreras sedan i UDDI (Universal Description, Discovery and Integration) som ett tecken på att en viss funktion eller funktionalitet är färdig att användas. Förrän en klient kan använda sig av, eller för att ta reda på vilka services som finns tillgängliga, så måste den ta kontakt med UDDI servern. UDDI servern svarar ifall att en match hittas med att skicka WSDL dokumentet till klienten. Klientens uppgift blir sedan att gå igenom dokumentet för att få reda på funktionsanropen och datatyperna. När det är färdigt är klienten färdig att plocka ihop ett XML dokument med funktionsanropen och variablerna. XML dokumentet packas in i ett SOAP kuvert som sedan skickas iväg till Web Servicen via HTTP protokollet. där det processeras. Beroende på om ett fel uppstått vid processeringen eller vid exekveringen av anropet skickas ett felmeddelande eller funktionens resultat tillbaka i ett XML dokument som är inpaketerat i ett SOAP kuvert. 3. Web Service Definition Language Web Service Definition Language (WSDL) är det medel med vilket man definierar gränssnittet till den service som finns tillgänglig. Detta görs med ett XML dokument. I dokumentet finns definierat följande [CCMW01]: Definitioner Typer Meddelanden Operationer Port typer Bindnings information

Port Service 3.1 Definitioner Definitionerna i WSDL dokumentet associerar namnen med specifika web services. 3.2 Typer Typ elementet definierar de typer som finns i ett meddelande. Eftersom dokumentet är i XML format kan också XSD (XML Schema) användas för att specificera data typerna. Datatyper som kan användas är bla. double, boolean, string, Array, base64binary (binära filer, tex bilder), datetime samt complex type (strukturer). 3.3 Meddelanden Meddelandena består av en eller flera logiska delar. Varje del är associerad med en typ. WSDL definierar meddelandena via XSD att innehålla ett namn, element samt en typ. Förutom dessa kan ett meddelande också innehålla en del (part) vilket gör att meddelandena kan användas som en flexibel väg att beskriva abstrakta delar av ett meddelande. Ett meddelande är per antagande abstrakt men kan göras konkret genom att binda meddelandet till den konkreta typ definitionen. 3.4 Operationer Operationerna (här vore det bättre att tala om funktioner eller procedurer) definierar ett abstrakt gränssnitt till de funktioner och eller procedurer som Web Servicen erbjuder. 3.5 Port typer En port typ är en mängd abstrakta operationer (en kanske dåligt vald term eftersom det kunde vara mera naturligt att tala om funktioner eller procedurer) och de abstrakta meddelanden som hör ihop med dessa. WSDL har fyra olika typer av transport primitiv (transmission primitives) som en ändpunkt kan ha för att flytta dessa meddelanden: 1. En vägs kommunikation (One-way) 2. Förfrågan Svar (Request-Response) 3. Svar Förfrågan (Solicit-response) 4. Notifikation (Notification)

Ändpunkten definieras dock inte ännu i detta skede. 3.5.1 En vägs kommunikation En vägs kommunikationen kan användas till att flytta data från en klient till tex en databas. Data flödar från klienten till servicen som då lagrar eller behandlar det på något sätt. Inget svar kommer tillbaka om hur vida operationen varit lyckad eller misslyckats totalt. Vi har endast sekvensen indata. 3.5.2 Förfrågan Svar Förfrågan torde vara den mest allmänna använda metoden eftersom den möjliggör att en funktion ger tillbaka ett svar till klienten. Det kan vara frågan om ett felmeddelande eller ett returvärde till indata. Vi har sekvensen indata, utdata. 3.5.3 Svar Förfrågan Servicen skickar ett meddelande åt klienten som svarar med ett meddelande. Det bör noteras att det är servern som initialiserar kommunikationen med att skicka ett meddelande åt klienten som sedan initialiserar sin egen kommunikation. Exempelvis autentikering där servern frågar efter ett på förhand bestämt kodat ord eller dylikt. Vi har sekvensen utdata, indata. 3.5.4 Notifikering Vid notifikering skickar servern ett meddelande till klienten. Det kan vara fråga om en nyhet, dvs data skuffas till klienten, tex som nyhets uppdatering en gång per 15 minuter. Vi har sekvensen utdata. 3.6 Bindnings Information En bindning definierar meddelandets format, protokoll detaljer för operationer och meddelanden för skilda porttyper. Ett meddelande inom en bindning specificerar därför grammatiken eller utseendet för indata, utdata och felmeddelanden. Här binds meddelandena ihop med den abstrakta definitionen. Åtminstone ett protokoll måste definieras för en bindning där protokollet i de flesta fall när man talar om Web Services är SOAP protokollet men det är också möjligt att använda tex CORBA eller DCOM.

3.7 Portar En port bestämmer ändpunkten eller slut adressen för meddelandena. En port får inte definiera mera än en adress. 3.8 Service En service grupperar ihop relaterade portar till en helhet. Portarna i en service har följande relationer [CCMW01]: Ingen av portarna kan kommunicera med varandra Om en service har flera portar som delar en viss porttyp men har skilda bindningar eller adresser så är portarna alternativ. Möjliggör för användaren av WSDL dokumentet att välja port beroende på data, mängd etc. Genom att granska porttyperna kan en användare av WSDL dokumentet bestämma om den vill kommunicera med en viss service eller inte. 3.9 Exempel Man kunde skriva flera sidor om WSDL dokumenten samt alla attribut som finns att tillgå. Detta kommer inte att göras här utan läsaren refereras till WSDL specifikationen [CCMW01]. Istället belyses WSDL dokumentet med ett exempel på hur ett dokument kan se ut.

<message name= GetFlightInfoInput > <part name = airlinename type= xsd:string /> <part name = flightnumber type= xsd:int /> </message> <message name= GetFlightInfoOutput > <part name = flightinfo type= fixed:flightinfotype /> </message> <message name= CheckInInput > <part name= body element= eticketxsd:ticket /> </message> <porttype name= AirPortServicePortType > <operation name= GetFlightInfo > <input message= tns:getflightinfoinput /> <output message= tns:getflightinfooutput /> </operation> <operation name= CheckIn > <input message= tns:checkininput /> </operation> </porttype> <binding name= AirportServiceSoapBinding type = TNS:AirportServicePortType > <soap:binding transport= http://schemas.xmlsoap.org/soap/http/ /> <operation name= GetFlightInfo > <soap:operation style= rpc soap:action= http://acme-travel/flightinfo/ /> <input> <soap:body use= encoded </input> <output> namespace= http://acme-travel.com/flightinfo encodingstyle= http://schemas.xmlsoap.org/soap/encoding /> <soap:body use= encoded </output> </operation> namespace= http://acme-travel.com/flightinfo encodingstyle= http://schemas.xmlsoap.org/soap/encoding /> <operation name= CheckIn > <soap:operation style= document <input> soap:action= http://acme-travel.com/checkin /> <soap:body use= literal /> </input> </operation> </binding> Tabell 1. WSDL abstrakt och konkret bindning [CDKN02] Vi har tre meddelanden, GetFlightInfoInput, GetFlightInfoOutput och CheckInInfo. Det första meddelandet, GetFlightInfoInput tar två parametrar, airlinename som är av typ sträng samt flightnumber som är av typen integer (förkortat int). I det andra meddelandet har GetFlightInfoOutput en parameter som är definierad annanstans som FlightInfoType (det är alltså möjligt att importera egna typdefinitioner). Samma gäller det sista meddelandet som tar emot en typ av Ticket. I porttype kan vi avläsa till vilka funktioner som meddelandena binds. GetFlightInfo har ett

indata och ett utdata meddelande (är således av typ förfrågan-svar), medan CheckIn endast tar en indata (en vägs kommunikation). För att få den abstrakta delen och fungera i praktiken binder vi ihop den till en konkret helhet i bindnings delen av WSDL dokumentet. Det första vi gör är att berätta vad bindningen heter och (i detta fall AirportServiceSoapBinding) vi säger samtidigt till vilken port typ den skall bindas samt vilket protokoll som kommer att användas för överflyttning, nämligen HTTP protokollet. För varje operation (eller funktion/procedur) bestämmer vi vilken SOAP metod som används (mera om detta senare), här är det RPC (Remote Procedure Call) samt Document (svaret tas som ett dokument). För operationernas input, output och fault (om så finns definierat) så bestämmer vi deras kodning samt vart de pekar (namespace elementet). Det sista som vi har kvar är att bestämma service delen, dvs sammanbinda det som byggts upp till en Web Service. <service name= travelservice > <port name= travelserviceport binding= tns:airportservicesoapbinding > <soap:address location= http://acme-travel.com/travelservice /> </port> </service> Tabell 2. WSDL konkret Service bindning [CDKN02] Här namnger vi Servicen, säger vilken porten är och vilken bindning som skall användas. Efter det säger vi var servicen finns tillgänglig med en http adress. 4. UDDI Men sen då när ett företag definierat och byggt upp sin WSDL fil och har alla funktioner och procedurer klara. Hur skall andra företag hitta dessa på ett så lätt sätt som möjligt? Om inte annat måste företaget med sin Web Service annonsera att de har en service att erbjuda och ge ut någon sorts specifikation (närmast då WSDL dokumentet eftersom det beskriver i detalj anropen samt vad som skickas tillbaka) åt de som är intresserade. Men till detta går det åt en massa onödig tid och pengar när man skall annonsera. Där kommer UDDI in. UDDI står för Universal Description, Discovery and Integration. UDDI är en Web Services sökmaskin i stil

med Google och andra i den bemärkelsen att ett företag kan registrera sin WSDL fil eller filer med annan information (som beskrivs senare) som sedan finns tillgänglig för andra att söka ifrån [UDDI.ORG02]. UDDI servicen är tänkt att från början vara så öppen som möjligt. Förutom Microsoft och IBM finns ett par hundra andra företag med i att utveckla UDDI specifikationen som för tillfället är uppe i version 3. 4.1 UDDI Server Strukturen Det finns ett antal root servers som dagligen replikerar med varandra. Tanken är att UDDI server strukturen skall vara så mycket som möjligt likt DNS (Domain Name System) med root servers som andra replikerar ifrån. De största, dvs. Microsoft och IBM är bland annat sådana som har en root server. I och med att man använder ett DNS liknande system så vill man visa att UDDI är en öppen teknologi där man litar på varandra samt att plattforms oberoende är en viktig del av teknologin. 4.2 UDDI Dokumenten UDDI dokumenten kan delas in i tre olika delar som liknar telefonkatalogen med vita och gula sidor samt en service typ register (Service Type Registration). Förutom dessa två finns ännu gröna sidor. Vita sidorna innehåller kontakt information till företag, gula sidorna innehåller kategoriserings data om företag eller taxonomier för att hjälpa till att söka efter specifika sektorer av industrier. De gröna sidorna består av information som beskriver hur man skall gå till väga för att använda deras service. Där finns bland annat bindnings information samt service beskrivningar, dvs allt som man behöver för att kunna ta en service i bruk. Service typ registreringen innehåller en pekare till namn rummet (namespace) där servicen finns beskriven samt information om vem som har gett ut informationen. De fyra UDDI dokumenten bildar alltså en helhet som innehåller all den information som man behöver för att söka efter en web service, få den förklarad samt hur man skall implementera sin klient för att den skall kunna använda sig av web servicen. För att kunna använda sig av

UDDI servicen finns en speciell API (Application Programming Interface) som bestämmer funktionerna som man kan använda för att kunna nå och använda den information som finns lagrad i registret. 4.3 UDDI Register Strukturen UDDI registret innehåller fyra centrala strukturer [SchEtAl02]: businessentity Strukturen som innehåller information om vita sidorna samt de gula sidornas taxonomier. Här finns all information lagrad om företagen. businessservice Den här strukturen innehåller informationen om Web Servicen eller en process beskrivning. Varje businessservice struktur innehåller en eller flera bindingtemplate som beskriver hur man hittar och binder sig till Web Services bindingtemplate Finns inom ramen för businessservice strukturen och innehåller detaljerad information om hur man hittar och använder en viss Web Service. tmodel Finns inom bindingtemplate strukturen och innehåller meta data om om varje service specifikation. Kallas också för Technical Model. Här finns specifikationen namn, vem som har publicerat den, URL:er till själva specifikationen. Varje specifikation som har registrerats i en tmodel i ett UDDI register får en egen unik ID, GUID. Bild 2. UDDI dokument strukturen [SchEtAl02] Det mest intressanta här är tmodel strukturen. I och med att den innehåller meta data kan man definiera genom den just vad som helst. tmodels primära funktion är att representera information om tekniska specifikationer. Där igenom är det naturligt att lagra i tmodel specifikationer om protokoll, tex SOAP, konverterings format osv. Specifikationen kan då

lagras i UDDI registret och kommunicerande partners kan då referera till den genom att ge den unika GUID:en som också kallat tmodelkey. tmodelkey fungerar som ett tekniskt fingeravtryck. Den andra viktiga saken med tmodel strukturen är att den stöder sök egenskapen i UDDI vilket är en viktig del eftersom man till största delen hittar information i UDDI genom att söka efter specifik information. I tmodel finns två strukturer, identifierbag och categorybag. identifierbag innehåller ett namn/värde par där namnet är namnet på ett företag och värdet är ett unikt nummer som identifierar företaget. categorybag innehåller taxonomi uppgifter på samma sätt som identifierbag genom att para ihop ett namn och ett värde som innehåller det taxonomiska värdet. <businessservice servicekey= 894B5100-3AAF-11D5-80DC-002035229C64 servicekey= D2033110-3AAF-11D5-80DC-002035229C64 > <name>electronictravelservice</name> <description xml:lang= en > Electronic Travel Service </description> <bindingtemplates> <bindingtemplate bindingkey= 6D665B10-3AAF-11D5-80DC-002035229C64 servicekey= 89470B40-3AAF-11D5-80DC-002035229C64 > <description> SOAP-based checkin and flight info </description> <accesspoint URLType= http > http://www.acme-travel.com/travelservice </accesspoint> <tmodelinstacedetails> <tmodelinstanceinfo tmodelkey= D2033110-3BGF-1KJH-234C-0987390982 >... </tmodelinstanceinfo> </tmodelinstancedetails> </bindingtemplate> </bindingtemplates> <categorybag>... </categorybag> </businessservice> <?xml version= 1.0 > <tmodel tmodelkey= > <name>http://www.travel.com/checkininterface</name> <description xml:lang= en > Standard service interface for travel service </description> <overviewdoc> <description xml:lang= en > WSDL Service Interface Document </description> <overviewurl> http://www.travel.com/services/e-checking.wsdl </overviewurl> </overviewdoc> <categorybag>... </categorybag> </tmodel> Tabell 3. Simplifierad businessservice och tmodel [CDNK02]

4.4 UDDI API När väl informationen som behövs för att kunna använda ens service finns ned skrivet är det dags för att skicka informationen till UDDI registret eller alternativt om man är programmerare så söka från UDDI registret efter en specifik service. Då kommer UDDI API:n väl tillhanda. API:n delas upp i två delar, förfrågnings delen samt publicerings delen. Utan att gå närmare in på detaljer om funktioner i båda delarna så finns det funktioner för att söka och publicera information om bindningar, företag, services, tmodeller etc. 4.5 UDDI kvalitet av service I UDDI finns inbyggt ett Quality of Service eller kvalitets kontroll. Om ett Web Service anrop av klinten misslyckas pga att kommunikationen till servern inte fungerar, Web Servicen har kraschat eller annars bara inte tar emot meddelanden så kan den som publicerat sin Web Service på UDDI servern updatera sin information och den som försökt kontakta Web Servicen kan ta ner den nya informationen [UDDI.ORG00]. Så om ett anrop misslyckas så bör då klienten gå till UDDI servern, ta hem den information som finns tillgänglig över den Web Service som används, jämföra den med den information som finns lagrat som proxy (se kapitel 5 om klienten). Om den just ner laddade informationen är nyare än den som finns lagrad så kan man ersätta den och försöka på nytt med ny Web Service data. Om informationen som man tog ner inte var ny, då kan man inte göra något annat än försöka på nytt. 5. Klienten Hur man implementerar klienten är upp till programmeraren. Man har åtminstone två olika alternativ. Det första är att göra en enskild klient med tex Java, Perl, C# eller Visual Basic. Det andra är att använda en web browser och implementera en www sida. Det första programmeraren gör är att han tar kontakt med ett UDDI register om han inte redan har specifikationen för en Web Service. Genom att söka efter partner företag eller via taxonomier hittar han säkert någon service som passar behoven. Efter att en passande Web Service har hittats laddas WSDL filen ner och för att göra kommunikationen bättre kan WSDL filen konverteras om till en proxy fil [MaNa02] som klienten tar kontakt med.

Alternativt kan man förbi gå proxyn och ta direkt kontakt med Web Servicen. Efter att WSDL filen har lästs igenom är det enda som återstår att implementera sin klient. Beroende lite på vilket språk och vilken server, tex Suns Java och Java server eller Microsofts.NET och C# eller Visual Basic så kan klienten implementeras på lite olika sätt. 6. SOAP Den bärande kraften bakom Web Services är SOAP (Simple Object Access Protocol) och är baserat på XML. SOAP är från början menat att vara lätt till specifikation och utvidningsbart [BoxEtAl00]. SOAP är menat som en envägs kommunikations modell men det är också möjligt att ha tvåvägs kommunikation så att både frågan och svaret skickas med SOAP. SOAP använder HTTP och HTTPS som transportmedel. Det är också möjligt att använda andra protokoll för att skicka SOAP meddelanden men i specifikationen för SOAP 1.2 är endast HTTP och HTTPS definierade. Andra möjliga protokoll som kunde användas är SMTP och FTP. Oberoende av vilket protokoll som SOAP använder sig av, är SOAP meddelandet skickat längs en väg (message path) vilket möjliggör att meddelandet kan processeras på flera olika ställen förrän det kommer till sin slutliga destination. Eftersom ett meddelande kan innehålla information som man inte vill att skall spridas så finns det en specifikation som definierar kryptering för SOAP meddelandena (mera om detta senare). Bild 3. Exempel på SOAP meddelande forwarding

Ovan ser vi en möjlig meddelande rutt. Ett meddelande skickas och kan ta vilken väg (den sträckade linjen) som helst förrän den kommer till en central hub (tex ett företags Web Service hub) som analyserar meddelandet (se nedan om processeringen) och beroende på innehållet och den fortsatta meddelande rutten skickas meddelandet vidare. 6.1 SOAP Processering En SOAP applikation som tar emot ett meddelande, om det sen är menat för det eller inte måste göra följande saker i ordning: 1. Identifierar alla delar i SOAP meddelandet som är menat för just den applikationen 2. Verifiera att alla obligatoriska delar som har blivit identifierade i steg 1 kan hanteras av applikationen och processera dem. Om inte så skall SOAP applikationen kasta bort meddelandet. 3. Om SOAP meddelandet inte var menat applikationen, ta då bort all information från meddelandet som var menat för applikationen och skicka meddelandet vidare. Processeringen av ett SOAP meddelande betyder att applikationen som gör processeringen förstår bland annat vad det betyder att ha envägs kommunikation, tvåvägs kommunikation och att det finns RPC mekanismer. 6.2 SOAP Meddelandet Ett SOAP meddelande kan delas upp i tre delar [BoxEtAl00]: Kuvert (Envelope) Huvud (Header) Kropp (Body) SOAP meddelandet måste innehålla ett kuvert, element namnet är Envelope. Kuvertet kan även innehålla andra definitioner så länge som dessa följer namn rums definitionen och är korrekta. Kuvertet i sig innehåller ett huvud och en kropp. Huvudet i SOAP meddelandet kan finns men behöver inte göra det. Om huvudet finns i SOAP meddelandet så måste det komma direkt efter kuvertet. Element namnet för huvudet är Head. Den sista delen i SOAP meddelandet, kroppen, måste existera efter ett kuvert eller ett huvud om sådant finns. Elementet som definierar kroppen heter Body. En speciell kropp existerar som heter Felmeddelande (Fault) vilken innehåller felmeddelande ifall att processeringen eller

exekveringen av meddelandet misslyckats. 6.2.1 Huvud elementet SOAP meddelandets huvud element är ett flexibelt element som kan användas för att förlänga SOAP meddelandets innehåll med tex autentikering, transaktions kontroll etc. Huvud elementet innehåller också två attribut som kan användas, dessa är actor samt mustunderstand. 6.2.1.1 actor Eftersom SOAP meddelanden kan skickas vidare via en rutt som kan innehålla en stor mängd SOAP applikationer (där en SOAP applikation som finns på vägen antas kunna ta emot och skicka vidare meddelanden) måste alla applikationer på vägen till den slutliga destinationen anges. Eftersom hela meddelandet inte troligen gäller för alla applikationer längs rutten så måste applikationen som tar emot meddelandet (om det inte är den slutliga destinationen) ta bort den information från meddelandet som angår den och skicka vidare meddelandet (som i 6.1 punkt 3). Applikationen som tagit emot meddelandet kan sätta in ett nytt huvud element men informationen som finns i det huvudet gäller endast den applikationen och den applikation som finns på ruttens slut. Actor elementet kommer med i bilden genom att det kan användas som ett globalt attribut som berättar vilken applikation som är den som i sista hand tar hand om meddelandet. Om attributet saknas så är mottagaren meddelandets slutliga destination. [BoxEtAl00] 6.2.1.2 mustunderstand mustunderstand är ett globalt attribut som indikerar ifall att ett huvud element är obligatoriskt eller inte. Värdet 1 anger att det är obligatoriskt. Saknas mustunderstand så räknas det som 0 dvs som om huvud elementet kan läsas/förstås frivilligt. Om huvud elementet har ett mustunderstand attribut som är 1 betyder det att varje applikation som tar emot meddelandet måste kunna läsa och förstå det. Om inte så måste applikationen returnera meddelandet med ett felmeddelande. Detta betyder att semantiken av ett meddelande inte kan ändras utan av att man får reda på det om mustunderstand är satt till 1 [BoxEtAl00]. 6.2.2 Kroppen I SOAP meddelandet ger kroppen en metod att lätt skicka och byta information för den som är

mottagare av ett meddelande. Kroppen används ofta för att skicka data eller till RPC anrop. Kropp elementet kommer direkt efter kuvertet förutom om huvud elementet finns med. I så fall måste kroppen komma direkt efter huvudet. Fastän huvudet och kroppen är självständiga element så är de relaterade till varandra. Skillnaden mellan huvudet och kroppen är den att kroppen är till semantiken likt huvudet förutom att den saknar actor och mustunderstand med värdet 1 [BoxEtAl00]. 6.2.3 Fault SOAP meddelandets fault element används som namnet säger till att transportera felmeddelanden i meddelandet. Om fault elementet existerar i meddelandet så måste det existerar i kropp elementet och får inte förekomma mer än en gång. Fault elementet definierar fyra sub element: faultcode används av programvaran för att ge en mekanism med vilket man kan identifiera ett fel. Om ett fel uppståt måste det här elementet vara med i fault elementet. Elementet kan innehålla tex VersionMismatch, MustUnderstand, Client, Server. I vissa fall där tex klienten är misskonfiguerad lönar det sig inte att skicka meddelandet på nytt förrän klienten är konfigurerad på rätt sätt, i andra fall där tex servern är nere och man får ett Server felmeddelande så kan man vänta en stund och skicka meddelandet på nytt. faulstring information om vad som har gått fel. Kan jämföras med HTTP protokollets felmedelande i stil med Sidan kunde inte laddas.... detail innehåller fel information om kroppen ifall att applikationen inte kunde processera kroppen i ett SOAP meddelande och måste finns med i ett fel meddelande. Om detta element inte finns med i ett felmeddelande så är det ett direkt bevis på att felet inte gäller kroppen. På så sätt kan man avgöra om kroppen blivit processerad eller inte [BoxEtAl00]. Andra felmeddelande typer kan finns med så länge de följer namn rums standarden. 6.3 SOAP och HTTP Genom att binda SOAP till HTTP (fastän det kunde även bindas till säg SMTP eller FTP) kan man använda SOAP protokollets flexibilitet samt HTTP protokollets vida spridning. SOAP ersätter inte på något sätt HTTP protokollet utan det mappas ganska naturligt in på HTTP och

dess semantik [BoxEtAl00]. SOAP följer HTTP förfrågan/svar meddelande modellen vilket möjliggör att SOAP förfrågans parametrar bakas in i HTTP förfrågan och SOAP svaren i HTTP svaren. SOAP lägger till ett fält till HTTP headern som heter SOAPAction vilket kan användas för att indikera vart meddelandet är på väg. En HTTP klient måste alltid använda SOAPAction när den skickar ett SOAP HTTP meddelande. SOAPAction kan användas av tex en brandmur för att filtrera HTTP trafiken eller dylikt. <SOAP:Envelope xmlns:soap= http://schemas.xmlsoap.org/soap/envelope/ > <SOAP:Header>... </SOAP:Header> <SOAP:Body>... </SOAP:Body> </SOAP:Envelope> Tabell 4. SOAP meddelandets sturktur [CDKN02] POST /travelservice SOAPAction: http://www.acme-travel.com/checkin Content-Type: text/xml: charset= utf-8 Content-Length: nnnn <SOAP:Envelope xmlns:soap= http://schemas.xmlsoap.org/soap/envelope/ > <SOAP:Body> <et:eticket xmlns:et= http://www.acme-travel.com/eticket/schema/ > <et:passengername first= Joe last= Smith /> <et:flightinfo airlinename= AA flightnumber= 1111 departuredate= 2002-01-01 departuretime= 1905 /> </et:eticket> </SOAP:Body> </SOAP:Envelope> Tabell 5. Exempel på SOAP meddelande [CDKN02] I den ovanstående tabellen har vi ett SOAP meddelande som skickats via HTTP. SOAPAction säger att vår avsikt är att nå checkin. Meddelandet saknar huvud men kroppen innehåller information om en elektronisk flygbiljett (eticket) där biljetten definierats i ett schema av den som producerar tjänsten. SOAP HTTP svaret använder sig likaså av HTTP protokollet. Status koderna för SOAP

meddelandena följer det som HTTP definierar. Tex ett svar med status koden 2xx betyder att SOAP meddelandet har tagits emot, blivit förstått samt processerat och accepterat. Om ett fel uppstår vid processeringen av meddelandet måst SOAP HTTP servern svara med ett HTTP 500 Internal Server Error felmeddelande samt inkludera i svaret fault elementet med all nödvändig information om felet som uppstått. 6.4 SOAP och RPC SOAP med RPC (Remote Procedure Call) fungerar i stort sätt på samma sätt som SOAP och HTTP. Funktions och procedur anropen flyttas med HTTP protokollet i SOAP format. För att göra ett anrop till en funktion eller procedur (SOAP 1.2 specifikationen talar om metod) så behövs följande information [BoxEtAl00]: URI (Uniform Resource Identifier) till objektet som anropas Funktions/procedur namn (metod namn) Parametrar till funktionen/proceduren Extra huvud data Möjlig metod signatur (method signature) RPC anropen och svaren skickas i SOAP kroppen användande följande representation: Ett funktions/procedur anrop modelleras som en struktur (jmf C språket). Anropet ses som en helhet som innehåller ett element för in eller in/ut data. Helheten är oftast nämnd efter funktionen/proceduren Svaret modelleras också som en struktur (struct). Svaret är en helhet som innehåller ett element för in eller in/ut data. Per konvention tilläggs strängen Respons till metodnamnet. Felmeddelande kodas enligt SOAP fault elementet. Ett svar kan aldrig innehålla både funktions eller procedur svar och ett felmeddelande. En SOAP applikation kan processera ett anrop till en funktion eller procedur fastän alla parametrar inte givits men applikationen kan även generera ett felmeddelande. I SOAP huvudet kan extra information läggas som tex transaktions data eller annan data som inte kan transporteras i kroppen men som man ändå vill ha transporterat med meddelandet.

POST /travelservice SOAPAction: http://www.acme-travel.com/flightinfo Content-Type: text/xml: charset= utf-8 Content-Length: nnnn <SOAP:Envelope xmlns: SOAP= http://schemas.xmlsoap.org/soap/envelope/ > <SOAP:Body> <m:getflightinfo xmlns:m= http://www.acme-travel.com/flightinfo SOAP:encodingStyle= http://schemas.xmlsoap.org/soap/encoding xmlns:xsd= http://www.w3.org/2001/xmlschema xmlns:xsi= http://www.w3.org/2001/xmlschema-instance > <airlinename xsi:type= xsd:string >UL</airlineName> <flightnumber xsi:type= xsd:int >506</flightNumber> </m:getflightinfo> </SOAP:Body> </SOAP:Envelope> Tabell 6. SOAP RPC anrop [CDKN02] I meddelandet ovan har ger vi två värden åt GetFlightInfo funktionen, airlinename som är av typ sträng och flightnumber som är av typ integer. Vi har även för funktionen definierat (encodingstyle) hur meddelandet skall avkodas. Egentligen kan SOAP meddelanden endast avkodas på ett sätt, nämligen det som finns definierat i SOAP specifikationen. Ett möjligt svar på anropet ovan i tabell 6 kan ses nedan: HTTP/1.1 200 OK Content-Type: text/xml: charset= utf-8 Content-Length: nnnn <SOAP:Envelope xmlns:soap= http://schemas.xmlsoap.org/soap/envelope/ > <SOAP:Body> <m:getflightinforesponse xmlns:m= http://www.acme-travel.com/flightinfo SOAP:encodingStyle= http://schemas.xmlsoap.org/soap/encoding/ xmlns:xsd= http://www.w3.org/2001/xmlschema xmlns:xsi= http://www.w3.org/2001/xmlschema-instance > <flightinfo> <gate xsi:type= xsd:int >10</gate> <status xsi:type= xsd:string >ON TIME</status> </flightinfo> </m:getflightinforesponse> </SOAP:Body> </SOAP:Envelope> Tabell 7. SOAP RPC svar [CDKN02]

Vi ser ovan att för det första har meddelande blivit accepterat och processerat i och med att HTTP Servern har packat in SOAP svaret med status 200. För det andra så ser vi att GetFlightInfo har blivit till GetFlightInfoResponse så vi kan förvänta oss att svaret på vår förfrågan finns inne i metod strukturen. Inne i GetFlightInfoResponse finns två nya element, våra retur värden, gate och status. Gate är definierat som en integer och status som en sträng. Vi kan låta vår klient gå igenom meddelandet och läsa det för oss. 7. Servern Server sidans implementering skiljer sig inte så mycket från klientens. Man har ett program som innehåller funktioner och procedurer. När ett SOAP meddelande kommer in till servern skickas det till SOAP applikationen som analyserar meddelandet och går igenom och ser att allt stämmer och att meddelandet verkligen var menat för det. Högst antagligen finns det nån sorts applikations server som som kör programmet med parametrarna som fåtts via meddelandet. Ett svar genereras om så är menat. Bild 4. SOAP Server struktur SOAP klienten skickar alltså ett SOAP meddelande som tar emot av SOAP Servern, må det sen vara IIS eller Apache eller nånting helt annat, men SOAP meddelandet processeras. Om meddelandet innehöll ett anrop till någon funktion så anropas funktionen eller sen kan data läsas eller alternativt skrivas till en databas eller så generaras ett nytt SOAP meddelande som

skickas iväg tillbaka till klienten som svar på funktions anropet den gjorde. 8. Säkerhet, autentikering, digitala underskrifter Eftersom SOAP protokollet använder sig av XML som skickas i ren text form passar SOAP dåligt som transport medel för att skicka känslig information som användar validering, bank transaktioner och dylikt vars innehåll man vill hålla hemligt för eventuella personer som lyssnar på trafiken mellan en SOAP klient och SOAP Applikation. För att möjliggöra sådana tjänster som autentikering eller skickande av användar namn och lösen så finns det en Web Service specifikation, Web Service Security som definierar kryptering av data i SOAP meddelandet samt digital underskrift. Det bör noteras att WS-Security är ännu endast ett förslag till standard för säkerhet i SOAP meddelanden. Till WS-Security hör kvaliteten av skyddet (Quality of Protection), Signaturer (Signature), dvs digital underskrift verifiering av integriteten. Meningen är att WS-Security skall uppfylla konfidentialitet, autentikering, integritet, garanti för att skickare inte kan säga att den inte skickat meddelandet samt givande av access till resurs [NHN02]. Kvaliteten av skyddet och signaturer kommer inte att behandlas här utan läsaren hänvisas till [AtkEtAl02] för en djupare insikt om ämnet. 8.1 Kryptering och SOAP WS-Security tillåter kryptering av vilken som helst kombination av kropp, huvud och deras barn element om sådana existerar samt kryptering av bilagor med antingen med en symmetrisk nyckel som delas av den som sänt meddelandet samt den som tar emot det eller sedan en nyckel som transporteras krypterad i själva meddelandet [AtkEtAl02]. WS-Security stöder sig helt på XML Encryption standarden vilken definierar tre element: ReferenceList EncryptedKey EncryptedData När man krypterar element eller elementets innehåll i ett SOAP meddelande kan man använda sig av ReferenceList elementet som beskriver de delar som är krypterade i meddelandet. Ett element eller element innehåll som skall krypteras måste ersättas med ett motsvarande

EncryptedData element. Alla EncryptedData element borde således vara listade inom ReferenceList elementet. Genom att koppla ihop ReferenceList och EncryptedKey kan man kryptera olika delar av ett SOAP meddelande med olika nycklar. När ett meddelande krypteras eller enskilda element innehåller en nyckel som i sin tur är krypterad med mottagarens nyckel och lagd till i meddelandet så kan EncryptedKey elementet användas för att transportera denna nyckel. Detta element borde listas i ReferenceList elementet och ha en motsvarighet till den listningen så att mottagaren vet vilka delar av meddelande är krypterat med denna nyckel. Om man skickar hela SOAP meddelandet krypterat eller lägga med bilagor kan dessa krypteras med EncryptedData elementet. För varje del av den krypterade bilagan måste ett krypterings steg dvs ett EncryptedData element läggas till samt följa följande regler [AtkElAl02]: Bilagan måste ersättas med den krypterade octet strängen (octet string) Den ersätta MIME (Multi-Purpose Internet Mail Extensions) media delen måste vara av typ applikation/octet-ström (application/octet-stream) Den originala media typen måste deklareras i EncryptedData elementet Den krypterade MIME delen måste refereras av ett CipherReference element med en URI som pekar på MIME delen Ett meddelande som krypteras måste efter krypteringen ännu vara ett äkta SOAP meddelande. Den som gjort meddelande får inte kryptera kuvertet, huvud eller kropp elementen, men nog deras under element. I annat fall förstörs SOAP meddelandets struktur. 9. Fördelar och nackdelar med SOAP SOAP protokollets och dess stöd protokoll, WSDL och UDDI, största fördelar är det att de bygger på en öppen struktur (XML) som kan utvidgas för att inkludera mera funktionalitet om så behövs. Det kanske mest viktiga är ändå att alla utvecklare av SOAP, WDSL och UDDI har kunnat samarbeta och bygga upp ett fungerande protokoll som baserar sig på redan existerande tekniker. SOAP är dock inte lösningen på allting. Det kan finnas tekniker som passar bättre för ett visst behov och det är upp till var och en att själv fundera ut vad som löser ens problem bäst. Som

tumregel kan man ändå säga att om man har som mål att få två totalt olika system på olika plattformer att fungera ihop så kan det löna sig att börja med att studera Web Services och vad SOAP kan erbjuda. Fördelen med SOAP är att den till motsats till CORBA och liknande är brandmurs vänlig dvs den använder sig av standard portar som redan är öppna och när man tar ibruk SOAP meddelanden så behöver man inte öppna nya hål i brandmuren utan man kan använda sig av existerande öppna portar. Nackdelar med SOAP och Web Services är för tillfället det att man ännu lever i en sorts hype där man inte kan vara riktigt säker på att vad som kommer att hända med hela begreppet. Visst det ser lovande ut men för tillfället vet man inte riktigt vad som kommer att hända i framtiden. Kommer de stora Web Service utvecklarna som IBM och Microsoft att också i framtiden kunna komma överens om hur det skall utvecklas och i vilken riktning. Det största hotet för tillfället är det att Microsoft och IBM slår ihop sig och besluter sins emellan om hur standarden skall utvecklas oberoende av tex W3C (WWW Consortium). Eftersom det är räknat att företag kommer att satsa cirka $2.2 miljarder på Web Service tjänster år 2003 och $25 miljader år 2008 så är det lätt att förstå att de stora först vill spela bort de mindre och sedan i slutet försöka slå ut varandra [Koc03]. Oberoende av detta så finns redan grunden lagd i och med SOAP protokollet. En sak som inverkar negativt på SOAP är att en svensk undersökning gjord på Blekinge högskola [ElPaLu02] har visat att SOAP jämfört med CORBA är en 400 gånger långsammare att skicka ett meddelande med. Genom att rucka på HTTP protokollets egenskaper kan detta fås ner till 7 gånger långsammare. Detta kan potentiellt leda till att i en situation där det skickas en massa meddelanden hela tiden så blir själva SOAP en flaskhals jämfört om man skulle genast ha tagit i bruk någon annan teknik. Detta ökar kostnaderna för infrastruktur för att få meddelandena processerade i god tid. 10. Verktyg Flere olika verkyg finns till för att generera de olika delarna av Web Services. Nedan listas några av de största samt länkar till WWW sidor där man kan få mera information.

10.1 SOAP Nedan några av de mera populära implementeringarna. Leverantör Språk Plattformer WWW Microsoft Visual Basic, C# Windows Http://msdn.microsoft.com/soap Apache Java UNIX, Windows Http://xml.apache.org/soap SOAP:Lite Perl UNIX, Windows Http://www.soaplite.com Systinet WASP C++, Java UNIX, Windows Http://www.systinet.com/wasp_overview.html GLUE Java UNIX, Windows Http://www.themindelectric.com/products/glue/glue.html Tabell 8. SOAP Implementeringar [SchEtAl02] 10.2 WSDL Eftersom WSDL är den teknik som kan sägas binda ihop SOAP och UDDI hittas oftast inte enskilda WSDL implementationer. I stället är de oftast en del av en verktygslåda (toolkit) [SchEtAl02]: The Microsoft SOAP Toolkit Stöder förutom WSDL också SOAP och UDDI och är närmast menat för utvecklare som arbetar inom Windows miljön. The IBM Web Services Toolkit (WSTK) Inkluderar WSDL, UDDI integration samt stöder IBM:s WebSphere applikations server. Innehåller också den öppna källkods WSDL för Java (WSDL4J) implementationen. 10.3 UDDI En lista på några av root UDDI root servrarna finns att tillgå på http://www.uddi.org/find.html. Där finns listade Microsoft, IBM, SAP, NTT samt länkar till deras UDDI servers. Det är också möjligt att bygga sin egen privata UDDI server. Det finns två alternativ: IBM:s UDDI server från http://www.alphaworks.ibm.com/tech/uddireg. Det finns också en UDDI implementation som bygger sig på den öppna källkoden och som är baserad på Java. juddi finns att fås från http://www.juddi.org. En lättare version av en UDDI server finns att få från Microsoft i samband med Microsofts UDDI SDK (Software Development Kit) som bygger sig på Microsoft.NET arkitektur. 11. Case ABB Library ABB Library är ABB Group världsomspännande konsernens digitala bibliotek dit dokument från hela världen samlas in angående produkter som ABB säljer samt dit hörande marknadsföring. För tillfället finns ca 62,000 dokument i bilioteket (November, 2003).

Dokumenten i biblioteket processeras i den takt de anländer och den samlade information publiceras ut på Internet där den är indexerad och sökbar. Samtidigt exporteras informationen i XML format till andra portaler inom ABB som kan dra nytta på så sätt av det som finns tillgängligt. Bild 5. ABB Library's struktur Data populeras i de olika länderna från användarens maskin till en lands server där data replikeras vidare till en central hub. I den centrala hub:en sker möjlig processering av data varefter den replikeras vidare till geografiska hub:ar som ligger så centralt som möjligt för att möjliggöra en snabb access till samlad data. Vidare exporteras data till en XML fil som finns tillgänglig för andra applikationer inom ABB som de kan ladda ner och processera för egna behov. 11.1 Web Service och ABB Library Vad kan Web Services göra för ABB Library? För det första så möjliggör det en transition från att upprätthålla flere gränssnitt (bla WWW och XML) till ett enda gränssnitt som andra använder sig av vilket leder till en drastisk simplifiering av nuvarande upprätthållning av processerna. Detta eftersom endast funktioner behöver upprätthållas och inte interface. Det bör dock noteras att en transition inte sker över en kort tidsperiod utan det kan vara frågan om två eller flere år förrän allt och alla har blivit flyttade till att använda bibliotekets Web Services. För det andra kan man implementera nya tjänster som: uppgradering av en lättare lokal kopia för mobila användare som inte har möjlighet

att använda direkt full data genom att markera de dokument eller kategorier av dokument som man vill att skall följas, antingen så att klienten skickar lista på dokument/kategorier som skall sökas igenom eller endast ett meddelande som väcker servern som söker igenom databasen och skickar en lista på förändrare dokument som man velat följa. Genom att implementera denna funktion via web läsaren kan man undgå nya klient applikationer notifikering av nya dokument versioner för användare eller förändring av status egen koncern autentikerings service för utomstående användare till biblioteket där dokument publicerare/ägare själva kan administrera rättigheter efter behov, kan även utvidgas till att inkludera andra service portalers autentikering populering och administration av dokument delande av dokument med kunder och sammarbets kumpaner 11.2 ABB Konsernen och Web Services Web Services har en del att erbjuda ABB Library men också ABB koncernen världen över genom att tekniken ger en bättre möjlighet till att vidare utveckla och koppla ihop business system än vad man har haft förut. Man kunde upprätta en egen UDDI server, sammanbinda produktionsstyrnings system, öka business till business (B2B) med leverantörer, underleverantörer och kunder genom att gränssnitten mellan företagen och applikationerna blir lättare att implementera eftersom kommunikationen följer ett redan etablerat protokoll [Jep01].

Referenser [AtkEtAl02] B. Atkinson Et Al, Specification: Web Services Security (WS-Security), http://www- 106.ibm.com/developerworks/ webservices/library/ws- secure/ April 2002, Checked 2003-10-30 [AMS02] S. Aissi, P. Malu, K. Srinivasan, E-Business Process Modeling: The Next Big Step, IEEE Computer, May 2002 [BoxEtAl00] D. Box et al, Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/tr/soap/, Checked 2003-10-12 [CCMW01] E. Chistensen, F. Curbera, G. Meredith, S. Weerawarana, Web Services Description Language (WSDL) 1.1, http://www.w3.org/tr/wsdl, Checked 2003-10-12 [CDKN02] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, Unraviling the Web Services Web, IEEE Internet, March 2002 [ElPaLu02] R. Elfwing, U. Paulsson, L. Lundberg: Performance of SOAP in Web Service Environment Compared to CORBA, Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC'02) [Jep01] T. Jepsen: SOAP Cleans up Interoperability Problems on the Web, IEEE IT Pro, January-February 2001 [Koc03] C. Koch: The Battle for Web Services, CIO Magazine, 2003, http://www.cio.com/archive/100103/standards.html, Checked 2003-11-17 [MaNa02] A. Mani, A. Nagarajan, Understanding quality of service for Web services, http://www- 106.ibm.com/developerworks/webservices/library/ws-quality.html, Checked 2003-10-31 [NHN02] Y. Nakamur, S. Hada, R. Neyama, Towards the Integration of Web Services Security on Enterprise Environments, Proceedings of the 2002 Symposium on Applications and the Internet (SAINT'02w), 2002 [RoRa01] J. Roy, A. Ramanujan, Understanding Web Services, IEEE IT Pro, November- December 2001 [SchEtAl02] R. Schmelzer et al, XML and Web Services, Sams Publishing, 2002 [Sta03] S. Staab, Web Services: Been There, Done That?, IEEE Intelligent Systems, January-February 2003 [TilEtAl02] S. Tilley et al, Adoption Challenges in Migrating to Web Services, Proceedings of the Fourth International Workshop on Web Site Evolution (WSE'02), 2002 [UDDI.ORG00] UDDI.ORG, UDDI Technical White Paper, http://uddi.org/pubs/iru_uddi_technical_white_paper.pdf, September 2000. Checked 2003-10-12 [UDDI.ORG02] UDDI.ORG, UDDI Overview Presentation, http://uddi.org/pubs/uddi_overview_presentation.ppt, September 2002, Checked 2003-10-12 [Va-Ni02] S.J. Vaughan-Nichols: Web Services: Beyond the Hype, IEEE Computer, February 2002