Webbtjänster med SOAP, uppbyggnad och implementation

Webbtjänster med SOAP, uppbyggnad och implementation David Smedman Institutionen för informationsbehandling Åbo Akademi, Åbo, Finland E-post: dsmedman(snabela)abo.fi

Abstrakt Denna uppsats kommer att ta upp användningen och de viktigaste begreppen inom begreppet Web services, som härstammar från utvecklandet av SOAP i början av år 2000 [1]. Jag kommer att ta upp de viktiga byggstenarna SOAP och WSDL som båda är uppbyggda av XML. SOAP är ett protokoll som används för att distribuera data mellan olika system över Internet. WSDL är ett definitionsschema för att definiera en Web service och används både av servern och av klienten i en Web service omgivning. Jag kommer också att nämna UDDI som gör det möjligt för serviceanvändare att hitta kontaktinformation och gränssnitt till publika Web services. Vidare kommer jag att visa ett exempel på användningen av Web services i ett projekt som har utförts vid Åbo Akademi. I detta exempel ser vi tydligt hur Web services kan användas för kommunikation mellan två system på olika platformer. Slutligen kommer jag också att ta upp olika Web services implementationer, exempel på sådana är.net och J2EE. Nyckelord Webbtjänst, SOAP, WSDL, XML, UDDI, MinPlan.

Innehållsförteckning: 1.Inledning 1 2. XML 2 2.1. Uppbyggna 2 2.2 Namnrymd 2 3. SOAP 3 3.2 SOAP meddelandens uppbyggnad 4 3.3 Felmeddelanden 4 3.4 Processering 5 4 WSDL 5 4.1 Typer 6 4.2 Meddelanden 6 4.3 Port typer och Portar 6 4.4 Service och det slutliga WSDL-dokumentet 8 5. UDDI 8 5.1 UDDI organisationen 9 5.2 UDDI i praktiken 9 5.2.1 UDDI information 10 5.2.2 UDDI register datastrukturen 10 5.3 UDDI SOAP API 12 6. SOAP webbtjänst implementationer 13 7. En webbtjänst i praktiken 14 7.1 Systemens uppbyggnad 14 7.2 Informationsutbytet mellan systemen 17 8. Avslutning 17 Litteraturförteckning 19

1 1. Inledning Informationsflödet bara ökar för de moderna företagen. I takt med att mer och mer av denna information digitaliseras och samlas i olika typer av databaser framträder ett behov av att också dela ut data till andra i digital form. Eftersom allt fler väljer att utveckla ett stort datasystem som täcker hela organisationens behov blir det allt vanligare att man även vill integrera sin omgivning. För att göra detta krävs det att man kan kommunicera med omgivningen på ett enkelt och standardiserat sätt. Ofta kan datasystemen vara uppbyggda på helt olika platformer, vilket gör kommunikationen ännu svårare. Ett sätt att uppnå platformoberoende standardiserad kommunikation är webbtjänster. Webbtjänster har blivit en allt mer använd standard sen dess uppkomst runt år 2000. Numera finns det ett register som erbjuder företag att registrera och söka bland många olika webbtjänster. Bild 1. Kommunikationsflödet i en webbtjänst [1]. För att möjliggöra kommunikation mellan två olika applikationer krävs det ett gemensamt språk. I detta fall är det XML (extensible Markup Language) som är det gemensamma språket. För att överföra XML-meddelanden till ett format som en viss applikation kräver används SOAP (Simple Object Access Protocol) och föra att beskriva hur SOAP-meddelandet ska se ut behövs ett beskrivningsspråk i form av WSDL (Webservice Description Language). Dessa tre bildar stommen i vad som kan kallas en webbtjänst. Föra att en användare lätt ska kunna hitta webbtjänster har ett register som kallas UDDI utvecklats. Jag kommer nu att gå igenom vad dessa huvuddelar och till sist belysa teorin med ett exempel som är hämtat från Åbo Akademi.

2 2. XML (extensible Markup Language) För att man lättare ska förstå de olika delarna i en webbtjänst kommer jag nu att ge en kort introduktion till hur XML är uppbyggt. XML är sedan 1998 accepterat av W3C som är ett konsortium som jobbar för att standardisera format och protokoll för Internet. XML skapades, till skillnad från HTML, inte för att beskriva hur data ser ut utan att beskriva vad data är. En annan skillnad gentemot HTML är att XML inte har några fördefinierade taggar. Man definierar alltså alla taggar själv. Man kan förutom att definiera element som beskriver data också bilda strukturer som grupperar data. 2.1. Uppbyggnad Ett element i XML måste, till skillnad från HTML, alltid ha en sluttagg. Det är också viktigt att element inte är nästlade. Följande exempel visar hur en struktur av typen meddelande kunde se ut: <message> <from xs:string>john</from> <to>jane</from> <text>hej Jane</text> </message> I detta exempel definieras elementet from som en sträng, vilket är en av flera typer som finns färdigt definierade i XML. 2.2 Namnrymd Något som är viktigt att ta upp i samband med XML är namnrymder. Då man definierar egna element är det mycket viktigt att samma namn inte används två gånger. Detta kan lätt hända vid implementeringen av webbtjänster, då man ofta har ett dokument uppdelat i flera olika filer. För att undvika att få dubbla element med samma namn kan man definiera olika namnrymd för båda elementen. För att peka på en namnrymd kan man använda sig av en URI (Uniform Resouce Identifier). Den

3 vanligaste typen av URI är en URL (Uniform Resource Locator). Ett exempel på användningen av namnrymder är att definiera en egen typ av tabell i ett dokument som innehåller en HTML tabell. HTML-tabellen kunde definieras på följande sätt: <table xmlns="http://www.w3.org/tr/html4/"> </table> Den egendefinierade tabellen kunde istället peka på en egen namnrymd på följande sätt: <table xmlns="http://www.abo.fi/~dsmedman/"> <table> Det är alltså attributet xmlns som anger namnrymden. Webbtjänster kommunicerar med meddelanden uppbyggda av XML [2]. 3. SOAP (Simple Object Access Protocol) SOAP är en av de viktigaste byggstenarna i en webbtjänst, eftersom det möjliggör kommunikation mellan användare. SOAP är ett lättvikts protokoll för att skicka och ta emot information i en distribuerande omgivning [3]. SOAP är baserat på XML (Extended Mark-up Language) meddelanden och det erbjuder ett sätt att skicka strukturerad information via http eller https[4]. Den stora fördelen är att mottagaren och sändaren inte behöver känna till varandra utan båda har en sk. SOAP-processor som kan tolka SOAP-meddelanden och deras data så att den underliggande plattformen kan använda dem. Ett exempel är en java SOAP-processor som omvandlar informationen i ett SOAP-meddelande till en instans av ett objekt eller till en java datatyp. På detta sätt kan den tjänst som erbjuder servicen ligga på en helt annan plattform och vara skriven i ett helt annat programmeringsspråk än den som använder servicen. Detta erbjuder ett affärsföretag att exponera delar av sina affärsdata för t.ex. kunder och andra intressenter, utan att dessa annars är en del av affärssystemet. Ett SOAP-meddelande består av tre komponenter. Dessa är kuvert (Envelope), rubrik (Header) och kropp (Body).

4 3.2 SOAP-meddelandens uppbyggnad Kuvertet är det som anger att XML-dokumentet är ett SOAP-meddelande. Kuvertet innehåller både huvudet och kroppen och därmed specificerar det också början och slut på meddelandet. Detta löser eventuella problem med att mottagaren inte vet när meddelandet slutar. Ifall mottagarens SOAP-processor kommer till kuvertets sluttagg vet den att meddelandet är slut och data kan bearbetas [3]. I rubriken kan man specificera hur mottagarens SOAP-processor ska bearbeta meddelandet. Rubriken behöver inte finnas med i meddelandet men om den finns med måste den komma som första element under kuvertet. Ett SOAP-meddeland har ofta en absolut slutpunkt men kan på sin väg till denna slutpunkt passera flera olika applikationer. I vissa fall kan det finnas information som är menad bara för ett av dessa delmål. Detta finns angett i rubriken [4] med hjälp av attributet actor, som anger vilken applikation som är den absolut sista i kedjan. Ett annat attribut i rubriken är mustunderstand. Detta attribut används också då ett meddelande sänd i en kedja mellan olika applikationer och signalerar för element som alla applikationer måste förstå.. Ifall mustunderstand är satt till 1, så måste en applikation som inte förstår elementet returnera ett felmeddelande som svar. I rubriken kan man också ange information om eventuell autenticering eller transaktionsprotokoll [4]. Kroppen i ett SOAP-meddelande är själva informationen som skall skickas. Kroppen måste följa eventuella reglerna som är satta i rubriken och den ligger under kuvertet och eventuell rubrik [4]. Ett enkelt exempel är en Webbtjänst som tar emot ett id och returnerar ett pris på en vara med motsvarande id. I detta enkla fall kommer det meddelande, eller begäran, som skickas till servicen ha numret i sin kropp. Servisen kommer i sin tur att returnera ett meddelande med priset i kroppen. Det existerar även en speciell typ av kropp, som heter felmeddelande (Fault) [3]. 3.3 Felmeddelanden

5 Felmeddelanden används för att meddela avsändaren att något har gått fel och att det aktuella meddelandet inte går att processera. Felmeddelandet ska finnas i kroppen och bör endast bestå av ett element och de egna underelementen. Om man inkluderar annan information i form av andra element kan inte meddelandet tolkas som ett felmeddelande. I felmeddelandet måste det finnas en felkod som anger bl.a. vem som orsakade felet, sändaren eller mottagaren. Det andra obligatoriska underelementet är ett orsakselement, som är till för att ge en mer konkret förklaring av felet och ges oftast i klartext [5]. Meddelandet kan även innehålla fler underelement men dessa är inte obligatoriska. 3.4 Processering För att en applikation ska kunna navända informationen i ett SOAP-meddelande måste det gå att översätta informationen till en form som applikationen förstår. Detta sker med hjälp av en SOAP-processor. Följande steg ska göras vid processeringen. 1. Kontrollera vad i innehållet som är menat för denna destination. 2. Kontrollera att alla delar som är menat för applikationen kan förstås och användas. Om inte så skall ett felmeddelande skickas. 3. Ifall meddelandet inte var menat för applikationen, så skall all information om applikationen tas bort och meddelandet ska skickas vidare. För att en applikation skall förstå vilka datatyper som finns i meddelandet behövs ett WSDL-dokument som är delat mellan avsändaren och mottagaren. 4. WSDL Ett WSDL-dokument är en mängd definitioner samlade i ett XML-dokument. I roten av dokumentet finns ett element som innehåller alla definitionerna, som används för att definiera själva gränssnittet till den Webbtjänst som finns tillgänglig [5]. Gränssnitten är definierade som en samling operationer, som finns implementerade

6 vid en viss slutpunkt Ett WSDL-dokument är uppdelat i fem olika delar eller element. Dessa fem är: 1. Typer 2. Meddelanden 3. Port typer 4. Portar 5. Service 4.1 Typer Typer används för att definiera och identifiera olika data typer som används i de meddelanden som skickas mellan tjänsten och den anropande applikationen. Dokumentet är i XML-format och därför kan man använda XML:s egna definitioner för att definiera t.ex. string, double och boolean element. Ifall man vet vilken typ av applikation som kommer att ta emot meddelandet kan man även använda helt andra typsystem. Man kan också definiera egna så kallade Komplexa typer. Dessa kan bilda en struktur och bestå av t.ex. en string och ett boolean element. Vidare kan en komplex typ också innehålla element av andra komplexa typer. Tack vare detta är WSDL mycket flexibelt och lätt att bygga ut[4][6]. 4.2 Meddelanden Meddelanden består av en abstrakt definition av det data som ska skickas. Ett meddelande ska innehålla ett namn, ett element och en typ. Här definierar man alltså, på ett abstrakt vis, vilka parametrar som kommer att skickas. Element kan ses som parametrar som skickas till en funktion i ett traditionellt programmeringsspråk[6]. 4.3 Port typer och portar

7 Port typerna är en mängd av abstrakta operationer. Ifall man skulle jämföra med ett objektorienterat programmeringsspråk, så skulle operationer motsvara metoder, meddelanden skulle vara input och output och port typen skulle vara objektet. Varje operation hänför sig till ett input meddelande och ett output meddelande. Det är dessa meddelanden som definierades i punkt 2.2. Det är operationerna som berättar för en webbtjänst vilka typer av meddelanden som ska skickas. Det finns fyra olika typer av operationer i WSDL: 1. Envägs kommunikation 2. Fråga/Svar 3. Svar/Fråga 4. Notifikation Vid envägs kommunikation sänds ett meddelande utan förväntning på svar [4]. Ett exempel kan vara en avsändare som sänder data som ska lagras i en databas. Den som skickar data förväntar sig inget svar, bara att få sina data lagrade av den som erbjuder webbtjänsten. Vid Fråga/Svar kommunikation skickar avsändaren en förfrågan och förväntar sig ett svar av mottagaren [4]. Som exempel kan ges ett affärssystem som erbjuder sina kunder en webbtjänst som returnerar priset på en vara med ett givet id. Kunden skickar en fråga, som innehåller id och förväntar att få ett svar som innehåller ett pris. Vid Svar/fråga skickar avsändaren en förfrågan utan någon input data [4].I praktiken betyder detta att man skickar ett SOAP-meddelande som inte innehåller några typdefinitioner i dess kropp. Detta kan ses som en funktion som anropas utan att sända med några parametrar. En notifikation är en operation som definierar flera mottagare av ett meddelande. En notifikation kan alltså användas för att skicka ett meddelande till många olika webbtjänster. Detta kan t.ex. användas för att meddela om en speciell händelse eller för att synka olika system mot varandra.

8 Efter att operationerna har grupperats i port typer så måste de bindas till ett specifikt transportprotokoll och till en ändpunkt dit meddelandet skall skickas. Ett av de vanligaste protokollen för webbtjänster är SOAP. Efter att man har definierat en transport bindning ska man med hjälp av portar knyta samman port typerna och transportbindningen [6]. 4.5 Service och det slutliga WSDL-dokumentet En service sammanbinder flera relaterade portar och gör det möjligt att erbjuda olika kategorier av operationer som en helhet åt användare [5] Det är också servicen som binder samman portarna med en ändpunkt, dvs. var tjänsten finns och vad den heter. Följande relation finns mellan portar i en service: Ingen port kommunicerar med en annan port i samma service. Om portar delar en port typ men har olika bindningar, är portarna alternativ som båda erbjuder samma tjänst fast med olika transportprotokoll. Detta ger användaren en möjlighet att välja port beroende på användningsområde. Genom att granska portarna kan man avgöra om det är möjligt att använda sig av tjänsten utgående från vilka port typer som stöds. Efter att alla delar och element är definierade kan man lägga ihop delarna till en WSDL-fil och publicera den på Internet, förutsatt att man har en underliggande applikation som erbjuder exakt den tjänst som finns beskriven i WSDL-dokumentet. Det finns även en möjlighet att importera element som är definierade i en annan WSDL-fil. På detta vis kan man kombinera delar från olika filer till helt nya sammansättningar och tjänster. För att göra det lättare att publicera och hitta önskade webbtjänster har ett register kallat UDDI tagits fram av bland annat Microsoft, IBM och Ariba [4]. 5.UDDI the Universal Description, Discovery and Integration registry

9 Med hjälp av UDDI är det lättare att hitta en webbtjänst på basen av vissa kriterier. Ofta vet man vad man söker för tjänst men man vet inget namn på företaget som erbjuder tjänsten. I vissa fall vill man kanske jämföra olika tjänsters egenskaper. I bägge fallen krävs det en lite mer avancerad söktjänst och det är exakt vad UDDI erbjuder [4]. Man kan säga att UDDI är för webbtjänster som Gula sidorna är för tjänsteföretag. Det finns också möjlighet för utvecklare att ha kontakt med UDDI både vid utveckling och vid exekvering. 5.1 UDDI organisationen Från början var det Microsoft, IBM och Ariba som började samarbeta kring ett projekt att få igång användandet av webbtjänster. Gruppen bildade UDDI.org och bjöd in andra företag att delta. I början var det också det tre förstnämnda som var värdar för servrarna som tillhandahåller informationen i UDDI. På senare tid har också Hewlett-Packard och SAP anslutit som värdar [4]. Över 300 företag är nu medlemmar och 15 av dessa är med i arbetsgruppen som bestämmer över strategin och kursen på projektet. Operatörerna tillhandahåller både en testmiljö och en produktionsmiljö. På detta sätt kan utvecklare testa sin UDDI-klient förrän webbtjänsten laddas upp till databasen. 5.2 UDDI i praktiken Värdarna tillhandahåller alla varsin databas som tillsammans bildar UDDI-registret. Ett företag som vill lägga upp en webbtjänst kan vända sig till någon av värdarna och ladda upp sin tjänst. Varje dag replikerar värdarna med varandra och byter ny information. På detta sätt hålls informationen alltid synkroniserad på de olika servrarna och samma information fås från alla värdar. Om man vill uppdatera information måste det dock göras på samma databas som man skickade tjänsten till. Alla företag som försöker ladda upp en tjänst måste först kontrolleras och verifieras, så att alla uppgifter stämmer.

10 UDDI har två huvuddelar, registrering och sökning. Registrering innebär att ett företag lägger ut information om en webbtjänst och sökning innebär att någon söker och hittar en tjänst. Man kommunicerar med UDDI genom en SOAP API eller något av gränssnitten som värdarna tillhandahåller. Själva registreringen och sökningen fungerar i säg som en webbtjänst och värdarna tillhandahåller skilda WSDLdokument för båda operationerna. 5.2.1 UDDI Information Den information som finns tillgänglig i UDDI-registret är indelad i 3 kategorier eller sidor. I de vita sidorna finns namn, adress, kontaktinformation, namnet på webbsidan och annan identifieringsinformation. De gula sidorna anger vilken typ av företag, företagets placering och vilka produkter företaget erbjuder. All denna information är angiven enligt olika standardiserade klassifikationssystem. T.ex. till vilken typ av industri företaget hör. Slutligen innehåller de gröna sidorna teknisk information om själva tjänsten. Detta innefattar t.ex. hur man ska kommunicera med tjänsten, vilken typ av data som tjänsten kräver och vilken typ av data som tjänsten returnerar. Det är också i denna del som ett eventuellt WSDL-dokument finns. Genom att använda standardiserade klassifikationer för identifiering blir det mycket lätt att söka och lista tjänster enligt olika kategorier. En tjänst kan klassificeras enligt vilken typ av industri, typ av produkt och service och placering. 5.2.2 UDDI register datastrukturen Registreringsinformationen innehåller fem olika datastrukturtyper. Dessa datastrukturer innehåller i sig flera element av vilka vissa är obligatoriska. Här följer en kort presentation av de olika strukturerna: 1. businessentity:

11 Här finns all information om de gula och vita sidorna, dvs information om företaget, lagrad. Inom denna del finns också de tre följande angivna. 2. businessservice: Namn och beskrivning av tjänsten. Här finns t.ex. olika kategoriserings information. 3. bindingtemplate: bussinessservicen kan inehålla flera bindingtamplate, som innehåller detaljerad information om hur man kontaktar och binder sig till en tjänst. 4. tmodel: Denna den används vid sökning. Den innehåller information med vars hjälp man kan unikt identifiera tjänsten. 5. publisherassertion: Med denna del kan man uttrycka olika relationer mellan två eller fler businessentity strukturer. Dessa fem delar är alla definierade i ett XML-schema som har ett businessentity element som rotelement. Ett exempel på ett schema följer här [8]: <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= D2033110-3BGF-1KJH-234C-0987390982 > <name>http:// www.travel.com /checkininterface</name>

12 <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> I detta exempel används WSDL för att beskriva webbtjänsten men UDDI accepterar även andra typer av beskrivningsspråk. Exemplet ovan visar i vilket format data sänds till UDDI värden men ingalunda hur data lagras i slutändan. Huvudsaken är att data vid behov går att återskapas till en likadan XML-fil, den underliggande arkitekturen spelar ingen roll. 5.3 UDDI SOAP API UDDI API:n (Application programming interface) är delad för dem som lägger till information och de som söker och hämtar information. API för registrering erbjuder möjlighet att lägga in ny information och uppdatera eller radera gammal. API:n för sökning returnerar antingen en lista på tjänster eller detaljerad information om en enskild tjänst. För att använda en API måste man autentiseras av den operatör som tillhandahåller API:n. Man måste även använda API:n över krypterad HTTPS. I API:n för sökning ges möjlighet att söka efter bindningar, företag, relaterade företag, en service för ett visst företag och tmodell, vilken ger möjlighet att söka efter tjänster med liknande egenskaper. Om man redan har en unik nyckel för en tjänst kan man också få mer detaljerad information grupperad på samma sätt som ovan. API:n för registrering erbjuder en hel del operationer för insättning och administration av uppgifter. Man kan också radera och uppdatera delelement som t.ex. bindingelement och tmodeller.

13 Operatörerna kan begränsa mängden av information som ett företag kan ladda upp till servern. Bland annat kan man begränsa storleken på meddelandet eller antalet tmodeller. 6. SOAP webbtjänst implementationer. För att utveckla applikationer som använder sig av webbtjänster kan man använda sig av de färdiga moduler som finns till de flesta programmeringsspråk idag. Det centrala i dessa implementationer är att översätta det xml meddelande som tas emot till en form som applikationen kan använda. Man har också försökt förenkla utvecklandet av webbtjänsterna så långt som möjligt. Eftersom webbtjänster har blivit ett vanligt begrepp så finns stödet med till de flesta platformer. Här följer en presentation av de vanligaste implementationerna. Java har nyligen lanserat sitt Java Web Service Developer Pack http://java.sun.com/webservices/index.jsp till Java EE platformen. Med detta verktyg kan man skapa egna webbtjänster och alla nödvändiga dokument. Man kan enkelt binda XML scheman till java klasser och även java klasser till xml scheman för att kunna dela ut sin information. Det finns också färdigt inbyggda moduler för att göra tjänsterna mer säkra. Till Java finns även en populär lösning vid namn Apache Axis [11]. Denna implementation baserar sig på öppen källkod. Båda dessa lösningar genererar WSDL dokumenten automatiskt. Microsofts egen utvecklingsplatform.net har också egna implementationer av webbtjänster. Microsoft har valt att kalla modulen för WebMethods och dess specifikationer påminner ganska långt om Javas. Här finns även stöd för automatisk generering av WSDL dokument. [12] PHP har också från och med version 5.0 haft webbtjänster implementerat. Denna lösning erbjuder inget direkt stöd vid utvecklandet av webbtjänsterna utan är mera tänkt för att göra det möjligt för PHP-applikationer att kommunicera med webbtjänster.

14 7. En webbtjänst i praktiken I följande kapitel kommer vi nu att se på ett verkligt exempel på hur webbtjänster kan användas. I detta nu håller Åbo Akademi på och utvecklar ett studieplaneringssystem kallat MinPlan. Det är meningen att studeranden ska kunna planera sin studiegång och göra personliga studiescheman i en webbaserad miljö. Parallellt utvecklas också ett webbaserat resursbokningssystem för akademins resurser, såsom auditorier och videokanoner. Meningen är att bokningssystemet ska erbjuda en webbtjänst som MinPlan kan använda för att hämta information om bokningar som har gjorts på en viss kurs. I bokningsskedet har man alltså möjlighet att ange en kurs att boka för. Detta betyder att bokningssystemet i sin tur måste hämta information om kurser från MinPlan, vilket också görs med en webbtjänst. Exemplet kommer att visa hur enkelt två olika system kan kommunicera med varandra utan att veta något om den underliggande strukturen. 7.1 Systemens uppbyggnad Bokningssystemet är implementerat i PHP [9] och all data sparas i en MySQLdatabas [10]. PHP är ett skript språk som körs på en webbserver och kan bäddas in i HTML (Hyper Text Mark-up Language). MySQL är en av de största sql-databaserna och är gratis under en GPL-licens. För att MinPlan ska få tillgång till bokningar behövs en rutin i bokningssystemet som tar mot följande parametrar: kurskod, kursdecimal och versionsnummer. Dessa tre behövs för att unikt kunna identifiera en kurs. Rutinen ska returnera en lista med instanser av objekt av typ BookingType. Rutinen anropar en intern rutin som i sin tur sköter själva kommunikationen med databasen. Bokningssystemet använder också webbtjänster internt men det behövs inga WSDL-dokument då både servern och klienten är implementerade i PHP. Då MinPlan inte är implementerat i PHP krävs följande WSDL-dokument:

<?xml version ='1.0' encoding ='UTF-8'?> <definitions name='findbookings' targetnamespace='http://www.vasa.abo.fi/bookeval/server/' xmlns:tns1='http://www.vasa.abo.fi/bookeval/server/' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/ xmlns:xsd='http://www.w3.org/2001/xmlschema' xmlns:soapenc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/' xmlns='http://schemas.xmlsoap.org/wsdl/'> <types> <xsd:schema xmlns:xsd=http://www.w3.org/2001/xmlschema elementformdefault="qualified" targetnamespace="http://www.vasa.abo.fi/bookeval/server/"> <xsd:complextype name="idvaluetype"> <xsd:sequence> <xsd:element name="id" nillable="true" type="xsd:string"/> <xsd:element name="value" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="responsiblepersonlisttype"> <xsd:sequence> <xsd:element maxoccurs="unbounded" minoccurs="0" name="bookingperson" nillable="true" type="tns1:responsiblepersontype"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="responsiblepersontype"> <xsd:sequence> <xsd:element name="responsiblepersonid" nillable="true" type="xsd:string"/> <xsd:element name="responsiblepersonusername" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="resourcetype"> <xsd:sequence> <xsd:element name="resourceid" nillable="true" type="xsd:string"/> <xsd:element name="resourcecode" nillable="true" type="xsd:string"/> <xsd:element name="category" nillable="true" type="tns1:idvaluetype"/> <xsd:element name="subcategory" nillable="true" type="tns1:idvaluetype"/> <xsd:element name="responsibleperson" nillable="true" type="tns1:responsiblepersonlisttype"/> <xsd:element name="resourcename" nillable="true" type="xsd:string"/> <xsd:element name="resourcedescription" nillable="true" type="xsd:string"/> <xsd:element name="cityid" nillable="true" type="xsd:string"/> <xsd:element name="cityname" nillable="true" type="xsd:string"/> <xsd:element name="buildingid" nillable="true" type="xsd:string"/> <xsd:element name="buildingname" nillable="true" type="xsd:string"/> <xsd:element name="buildingaddress" nillable="true" type="xsd:string"/> <xsd:element name="buildingpobox" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="bookingtype"> <xsd:sequence> <xsd:element name="bookingnumber" nillable="true" type="xsd:string"/> <xsd:element name="coursecode" nillable="true" type="xsd:string"/> <xsd:element name="coursecodedecimal" nillable="true" type="xsd:string"/> <xsd:element name="courseversion" nillable="true" type="xsd:string"/> <xsd:element name="coursename" nillable="true" type="xsd:string"/> <xsd:element name="bookingpersonusername" nillable="true" type="xsd:string"/> <xsd:element name="bookedforpersonfirstname" nillable="true" type="xsd:string"/> <xsd:element name="bookedforpersonlastname" nillable="true" type="xsd:string"/> <xsd:element name="partialelement" nillable="true" type="tns1:idvaluetype"/> <xsd:element name="group" nillable="true" type="tns1:idvaluetype"/> <xsd:element name="startdate" nillable="true" type="xsd:string"/> <xsd:element name="starttime" nillable="true" type="xsd:string"/> <xsd:element name="enddate" nillable="true" type="xsd:string"/> <xsd:element name="endtime" nillable="true" type="xsd:string"/> <xsd:element name="commentswedish" nillable="true" type="xsd:string"/> <xsd:element name="commentenglish" nillable="true" type="xsd:string"/> <xsd:element name="resource" nillable="true" type="tns1:resourcetype"/> <xsd:element name="eventtextswedish" nillable="true" type="xsd:string"/> <xsd:element name="eventtextenglish" nillable="true" type="xsd:string"/> 15

16 <xsd:element name="languageid" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="bookingslisttype"> <xsd:sequence> <xsd:element maxoccurs="unbounded" minoccurs="0" name="booking" nillable="true" type="tns1:bookingtype"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="bookingssearchcriteriatype"> <xsd:sequence> <xsd:element name="courseinformationcoursecode" nillable="true" type="xsd:string"/> <xsd:element name="courseinformationcoursecodedecimal" nillable="true" type="xsd:string"/> <xsd:element name="courseinformationversionnumber" nillable="true" type="xsd:string"/> <xsd:element name="bookingid" nillable="true" type="xsd:string"/> <xsd:element name="language" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="bookingdatetype"> <xsd:sequence> <xsd:element name="year" type="xsd:string"/> <xsd:element name="month" type="xsd:string"/> <xsd:element name="day" type="xsd:string"/> </xsd:sequence> </xsd:complextype> <xsd:element name="bookinglist" type="tns1:bookingslisttype"/> <xsd:element name="bookingsearch" type="tns1:bookingssearchcriteriatype"/> </xsd:schema> </types> <message name='findbookingsrequest'> <wsdl:part name="findbookingsrequest" element="tns1:bookingsearch" ></wsdl:part> </message> <message name='findbookingsresponse'> <wsdl:part name="findbookingsresponse" element="tns1:bookinglist"></wsdl:part> </message> <porttype name='bookingsporttype'> <operation name='findbookings'> <input message='tns1:findbookingsrequest'/> <output message='tns1:findbookingsresponse'/> </operation> </porttype> <binding name='bookingsbinding' type='tns1:bookingsporttype'> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="findbookings"> <soap:operation soapaction="urn:#findbookings"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name='bookingsservice'> <port name='bookingsport' binding="tns1:bookingsbinding"> <soap:address location='http://www.vasa.abo.fi/bookeval/server/minplan-bookings.php'/> </port> </service> </definitions> Detta exempel visar hur man börjar med att definierar alla datatyper men också hur man definierar egna komplexa typer genom att gruppera flera olika element till en

17 struktur, t.ex. BookingType som dels består av färdigt definierade typer som string men också av andra komplexa typer som ResourceType. Vidare definieras vilka meddelanden som ska skickas. I detta fall kommer MinPlan att skicka ett findbookingsrequest meddelande av typen bookingsearch, som i sin tur är en instans av typen BookingSearchCriteriaType och bokningssystemet kommer att returnera ett findbookingsresponse meddelande av typ bookinglist. Efter detta sätts meddelandena in i en port typ, vilken sen binds till ett transportprotokoll. Till sist knyter vi bindningen till en ändpunkt där tjänsten finns. I detta fall är det http://www.vasa.abo.fi/bookeval/server/minplan-bookings.php och metoden findbookings, vilka tillsammans bildar slutpunkten. 7.2 Informationsutbytet mellan systemen Kommunikationen börjar med att MinPlan läser in WSDL-dokumentet som bokningssystemet erbjuder och omvandlar, med hjälp av en SOAP-processor, instansen av ett BookingSearchCriteriaType objekt till ett SOAP-meddelande i XML-format och skickar detta meddelande över https till bokningssystemet. Därefter översätter, med hjälp av samma WSDL-dokument, bokningssystemets SOAPprocessor meddelandet till en instans av ett objekt och gör sökningen med hjälp av de parametrar som finns i instansen. Rutinen kommer att returnera ett BookingType objekt som SOAP processorn omvandlar till ett nytt SOAP-meddelande. Detta meddelande skickas sen tillbaks till Minplan, som i sin tur processerar meddelandet. Efter detta är kommunikationen klar och MinPlan har fått den efterfrågade informationen. Detta visar tydligt hur systemen kan byta information trots att de annars är oberoende. 8. Avslutning Att kunna förmedla information från ett företag ut i dess omgivning, har på senare tid blivit allt viktigare. En enkel lösning på detta kunde vara att tillåta omgivningen att direkt operera på t.ex. databaser i forma av sökningar och insättningar. Det är dock i praktiken ingen bra idé att tillåta kommunikation direkt med den underliggande