Prestandaoptimering av Web Services i J2EE-miljö

Prestandaoptimering av Web Services i J2EE-miljö Hjalmar Jacobson TRITA-NA-E04103

NADA Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science 100 44 Stockholm Royal Institute of Technology SE-100 44 Stockholm, Sweden Prestandaoptimering av Web Services i J2EE-miljö Hjalmar Jacobson TRITA-NA-E04103 Examensarbete i datalogi om 20 poäng vid Matematisk-datalogiska linjens datalogiinriktning, Stockholms universitet år 2004 Handledare på Nada var Linda Kann Examinator var Stefan Arnborg

Referat Web services är en teknik som är uppbyggd kring XML och XMLbaserade protokoll (t.ex. SOAP), vilken gör det möjligt för applikationer att kommunicera oberoende av plattform och programmeringsspråk. Syftet med arbetet var att utreda hur prestanda i web services bäst optimeras i J2EE-miljöer. En undersökning angående skalbarhet och prestanda för web services vid olika belastning har gjorts. Framförallt har vi tittat på olika anropstyper, utseende på anropen samt olika XMLparsrar. Vi har kommit fram till att valet av anropstyp (sträng, heltal,...) inte har någon avgörande påverkan på prestanda. Inte heller har valet av XML-parser någon större betydelse. Vad som däremot har stor betydelse för prestanda och skalbarhet är hur anropen konstrueras. Eftersom anropen sker med XML kommer vi att transportera mycket meta-data. För att procentuellt minska den mängden bör vi om möjligt samla de många små anropen till flera stora. Vi bör även, vid utveckling av web services, tillåta och göra det möjligt för en klient att lagra XML-filer (så som WSDL). Vid jämförelse med RMI-anrop har vi sett att web services skalar sämre. Detta är inte särskilt konstigt då RMI-anrop till sin natur är binära. Dock kan det vara ett billigt pris att betala då vi i en web services får ett helt annat oberoende.

Performance Tuning of Web Services in J2EE Abstract Web services is a technique which is built on XML and XML based protocols (e.g. SOAP). This makes it possible for applications written in different languages and running on different systems to communicate with each other. The main purpose of this Master s thesis was to examine how to tune up the performance and scalability for web services in J2EE environments. We have looked into how different loads affect the performance; if the parameter types, the structure of the call or the choice of XML-parser makes any difference for the performance. When it comes to different parameter types, such as strings and integers, the use does not really affect the performance. Neither does the choice of XML-parser. What makes a major difference is the structure of the call. Since XML carries much meta-data, we want to reduce that overload. So if we try to unite the small calls into one or more greater calls, the overall overload will decrease. We also recommend that the web services allow clients to temporarily store some of the XML-files, such as WSDL. When comparing web services with RMI we found as we expected that web services have poorer performance. Despite this fact, the price one has to pay in poorer performance might not be so high, compared to the gain in interoperability.

Innehåll 1 Inledning...1 1.1 Uppgift...1 1.2 Uppdragsgivare...1 1.3 Upplägg av examensrapporten...2 2 J2EE...3 2.1 Distribuerade flerlagerarkitekturs-applikationer...3 2.2 J2EE Containrar...4 2.3 Paketering...5 2.4 J2EE API:er...5 3 Web services...12 3.1 XML...13 3.2 SOAP (Simple Object Access Protocol)...19 3.3 WSDL (Web Services Description Language)...23 3.4 Java API:s för XML...25 4 Skalbarhet och optimering i stora och komplexa J2EEapplikationer...32 4.1 Testspecifikation...32 4.2 Enkla web services-anrop...34 4.3 Olika datatyper...35 4.4 Olika parsrar...39 4.5 RMI versus web services...42 4.6 Slutsats...45 Referenser...49 Bilagor...50 A.1 XML (enkel syntax)...50 A.2 Java API:s för XML...57 A.3 Http...59 A.4 XML (avancerad syntax)...62 A.5 Servlet...69 A.6 EJB...69 A.7 Övriga J2EE API:er...73 A.8 SOAP...75 A.9 WSDL...76 A.10 JAXP...78 A.11 JAX-RPC...79 A.12 Testresultat...81 A.13 Tillåtelse att använda material från w3schools.com...89

1 Inledning Innehållet i detta arbete färdigställdes i december 2003. Ämnet som behandlas är under ständig förnyelse, varför en del i arbetet snabbt kan betraktas som gamla nyheter. På inrådan av min handledare Linda Kann på Nada har jag genomgående uttryckt mig i vi -form. 1.1 Uppgift Web services är en teknik eller ett sätt att kommunicera mellan applikationer oberoende av plattform och programmeringsspråk. Fördelen är bl.a. att olika tekniker kan utnyttja varandras starka sidor samt att uppgradering och integration av delsystem lättare kan genomföras. Web services som teknik bygger på standarder för anrop, visualisering av tjänster, transport av data med mera så som SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), XML (extensible Markup Language) och WSDL (Web Services Definition Language). Examensarbetets uppgift är att först beskriva web services som teknik, dvs. visa vilka byggstenar och standarder som finns för web services och hur dessa fungerar i allmänhet. Huvuduppgiften är dock att utreda hur web services skalar och optimeras i stora komplexa J2EE-applikationer. Som grund ska examensarbetet jämföra tidsskillnaden mellan RMI- och web services-anrop. Slutligen ska också olika XML-parsar som används vid web services jämföras och utredas. Sist ska vi försöka ge riktlinjer för hur web services ska implementeras och användas i J2EE-miljöer för att uppnå bäst prestanda. 1.1.1 Syfte Syftet med examensarbetet är att utreda hur prestanda i web services bäst optimeras i J2EE-miljöer. Vi vill utreda hur ett web services-anrop beter sig prestandamässigt; hur web services skalar. Vi vill också utreda på vilket sätt olika datatyper och XML-parsrar påverkar ett anrop, hur anropstiden påverkas samt hur olika delarna kan förbättras. 1.1.2 Mål Vi hoppas kunna ge en fingervisning om hur nära, tidsmässigt sett, ett optimerat web services-anrop är ett vanligt RMI-anrop. Målet är också att ge konkreta förslag på hur en befintlig web services kan optimeras, samt ge riktlinjer för hur en web services bör utvecklas och hur ett web services-anrop bör se ut. Examensarbetet ska utmynna i en skriftlig rapport med metodbeskrivning, utredning, slutsats, testresultat och kodexempel. 1.2 Uppdragsgivare R2M (R2Meton AB, http://www.r2m.se) är ett konsultföretag med inriktning på integration och transaktionsarkitektur. Kärnverksamheten har sedan starten 1996 utgjorts av kvalificerade konsulttjänster inom 1

projektledning, systemarkitektur och driftstrategier vid införande av flerlagerarkitektur i stora organisationer. Verksamheten består till stor del i att införa, utveckla och förvalta infrastruktur för driftkritiska applikationer i tjänstelager. De tekniska miljöer som är mest förekommande är J2EE, Oracle, Tuxedo samt tillhörande integrationsprodukter på Unix-plattformar. 1.3 Upplägg av examensarbetesrapporten Eftersom den web services vi ska undersöka är baserad på Java och J2EE (Enterprise Edition) börjar vi med en liten genomgång av J2EE, dess struktur och komponenter. (Läsaren förväntas vara väl insatt i objektorienterad programmering, framförallt Java.) Då en web services ofta representeras av en Servlet kommer vi gå in litet djupare i den delen av J2EE. Vi kommer även ta upp Enterprise Java Beans (framförallt Session EJB:s), då vi använder oss av den tekniken för att göra våra RMI-anrop. Även om vi inte använder oss av JSP (Java Server Pages) så kommer vi kort gå igenom det ändå, eftersom det är en viktig komponent i J2EE-standarden. När vi gått igenom denna (J2EE) teknik kan vi gå in på tekniken web services. Efter några inledande ord om web services går vi igenom vad XML är. Det är viktigt att vi har klart för oss vad XML är och hur det kan användas, för det är på XML som web services är uppbyggt. I en web services använder man sig inte av DTD eller XMLSchema (som båda är regler för XML-dokument), men eftersom de är viktiga för XML i sig berör vi dessa. Därefter kan vi gå igenom de olika XML-protokoll och Java XML- API:er som web services bygger på, så som SOAP, WSDL, UDDI, SAX, JAX-RPC Slutligen kan vi utföra de tester vi behöver göra för att utreda skalbarhet och optimering. Mycket material har placerats i bilagor, där den som vill kan gå djupare in i vissa ämnen. I arbetet finns många kod- och syntaxexempel. Det mesta är taget eller inspirerat från http://www.w3schools.com och http://www.java.sun.com. I princip är alla exempel som har med definitioner på XML, SOAP, WSDL och UDDI tagna från w3schools, vilket de godkänt (se bilaga A.13). 2

2 J2EE 1 Java 2 Enterprise Edition är en teknologi som gör det möjligt att, i utveckling och design, ha komponentbaserade lösningar. En av J2EEplattformens stora fördelar är dess enkelhet när vi vill utveckla distribuerade applikationer av flerlagerarkitektur. Det är väldigt lätt att återanvända komponenter, ha XML-baserat datautbyte, ha en enhetlig säkerhetskontroll och en flexibel transaktionskontroll. 2.1 Distribuerade flerlagerarkitekturs-applikationer Applikationsmodellen på J2EE-plattformen är en distribuerad flerlagerarkitektur där applikationslogiken är uppdelad på olika komponenter. Hur uppdelningen av affärslogiken går till beror på vilken funktionalitet som önskas. Komponenterna är sedan utplacerade/ installerade på olika maskiner beroende på vilket skikt de tillhör. Figur 2-1 är ett exempel på en sådan applikation som är uppdelad i följande skikt: klientskiktets komponenter som körs på klientmaskinen. webbskiktets komponenter som körs på J2EE-servern. affärsskiktets komponenter som körs på J2EE-servern. Enterprise information system (EIS)-skiktets mjukvara som körs på EIS-servern. Figur 2-1 Applikationslogiken på en J2EE-plattform är en distribuerad flerlagerarkitektur. Applikationslogiken är uppdelad på olika komponenter och ligger ofta på olika maskiner. Även om J2EE-applikationer kan innehålla tre eller fyra skikt, som i figuren 2-1, betraktas dem i allmänhet som treskiktsapplikationer eftersom de är distribuerade på tre olika ställen. 2.1.1 J2EE-komponenter En J2EE-komponent är en självgående funktionsenhet som kan kommunicera med andra komponenter. I J2EE-specifikationen finns 1 Alla kodexempel är hämtade från handledningen (tutorials) på http://www.java.sun.com 3

följande komponenter definierade: applikationer och applets som körs på klienten Java Servlet och JavaServerPages (JSP), vilka är webbkomponenter som körs på en server Enterprise JavaBeans (EJB) eller enterprise beans, vilka är affärskomponenter som körs på en server Skillnaden mellan J2EE-komponenter och standard-java-klasser är att J2EE-komponenterna är infogade, sammansatta, till en J2EE-applikation. 2.1.2 Webbkomponenter En J2EE-webbkomponent kan antingen vara en servlet eller en JSPsida. Servlets är Java-klasser som dynamiskt kan behandla förfrågningar och konstruera svar. JSP-sidor är textbaserade dokument som i körtid fungerar som servlets. Statiska HTML-sidor och applets brukar ofta hamna i det här facket, men ingen av dem är egentligen någon webbkomponent (enligt J2EE-specifikationen 2 ). 2.1.3 Affärskomponenter Affärskod, som är logik som möter det behov som för tillfället söks, sköts av enterprise beans som körs i affärsskiktet. I figur 2-2 ser vi hur en enterprise bean tar emot data från ett klientprogram, behandlar det och skickar det till EIS-skiktet för lagring. En enterprise bean kan också hämta data från EIS-skiktet, behandla det och skicka det tillbaka till klientprogrammet. Figur 2-2 Flödesdiagram för affärslogik i en J2EE-applikation. En enterprise bean tar emot data från ett klientprogram, eventuellt via ett mellanlager, behandlar det och skickar det till EIS-skiktet för lagring. Hämtning kan också ske från EIS-skiktet och skickas till klientprogrammet. 2.2 J2EE Containrar Utan containrar skulle en vanlig tunn flerlagerarkitekturs klientapplikation vara väldigt invecklad att skriva, men tack vare användandet av containrar slipper vi ta hänsyn till komplexa lågnivådetaljer som till exempel transaktioner, trådning och resursfördelning (pooling). 2 http://java.sun.com/j2ee/reference/api/index.html 4

En container är gränssnittet mellan en komponent och den, på lågnivå, plattformsspecifika funktionalitet som komponenten behöver. Innan en webb-, enterprise bean- eller en klientapplikationskomponent kan köras måste den infogas i en J2EE-applikation och placeras i sin respektive container. Infogningsprocessen involverar specificering av containerinställningar för komponenten i J2EE-applikationen. Containerinställningarna skräddarsyr den underliggande servicen som J2EE-servern står för, vilket innebär inställningar för bl.a. säkerhet, transaktion, Java Naming and Directory Interface (JNDI) -uppslagningar och fjärranslutningar. I och med att J2EE-arkitekturen erbjuder denna konfigurationsservice kan en applikationskomponent, inuti samma J2EE-applikation, bete sig olika beroende på var den är utplacerad. Containern handhar även icke-konfigurerbar service såsom livscykeln för en enterprise bean eller servlet, resursfördelning för databasåtkomst, datafortlevnad och tillgång till J2EE-plattforms-API. 2.3 Paketering J2EE-komponenter är paketerade separat och ihopsamlade till en J2EEapplikation för utplacering. Varje komponent, dess tillhörande filer (GIF, HTML,...) och en utplaceringsdeskriptor är sammansatt till en modul och som sedan kan läggas till i J2EE-applikationen. En J2EE-applikation, och varje av dess moduler, har sin egen utplaceringsdeskriptor. En utplaceringsdeskriptor är ett XML-dokument som beskriver en komponents utplaceringsinställningar. Tack vare användandet av moduler är det möjligt att sätta samman flera olika J2EE-applikationer och använda önskade komponenter. 2.4 J2EE API:er Det finns många API:er definierade i J2EE-standarden. Vi har valt att endast gå djupare in på några av dem. Framförallt har vi koncentrerat oss på de API:er vi har användning av i våra tester. 2.4.1 Java Servlet Servlets är Javakod som utökar funktionaliteten för en applikationsserver/webbserver ungefär på samma sätt som en applet gör för en webbläsare. En servlet är uppbyggd att fungera efter en förfrågningsoch svarsmodell (request/response), vilket i praktiken innebär att en klient skickar en förfrågan till en servlet, vilken returnerar ett svar. En servlet kan göra många saker, t.ex. kan den behandla ett HTMLformulär eller agera mellanhand mellan en klient och en databas. De olika förfrågningarna en klient gör är oftast baserat på något slags protokoll, t.ex. HTTP, URL, FTP eller t.o.m. ett egendefinierat protokoll. Java Servlet API:n innehåller gränssnitt som definierar kopplingen mellan servern och aktuell servlet. API:n består av paketen javax.servlet och javax.servlet.http. En servlet är till sin uppbyggnad effektiv, säker, pålitlig och kan lätt pluggas in i en redan befintlig server och där få del av ny funktionalitet. 5

2.4.1.1 Arkitektuella roller för servlets Mellanlagerprocess En servlet ligger som ett mellanlager och fungerar därmed som en länk mellan klienterna och serverns bakomliggande tjänster. På detta sätt får man en tunnare klient och servern kan fokusera på sina egentliga uppgifter. Proxy servers En servlet kan agera proxyserver till en applet. (En applet får endast skapa kopplingar tillbaka dit den kom ifrån.) Om en applet behöver skapa en koppling mot en annan server kan vi låta en servlet göra den kopplingen. På så sätt går vi runt begränsningen. Protokollsupport Servlet API:n fungerar som en länk mellan servern och en servlet. Detta gör det möjligt för en servlet att ge en server support för nya protokoll. HTTP-protokollet finns det redan stöd för, men i princip kan varje protokoll som använder sig av en förfrågnings/svars-modell implementeras av en servlet (t.ex. SMTP, POP och FTP). 2.4.1.2 Installering av servlets En servlet körs inte på samma sätt som en applet eller applikation. En servlet utökar ju funktionaliteten hos en server, så först måste en servlet installeras och sedan måste någon göra en förfrågan mot den. Temporära versus permanenta servlets En servlet kan startas/stoppas vid varje klientförfrågan (temporär) eller startas vid uppstarten av servern och stoppas vid stoppningen av servern (permanent). Det är ingen skillnad, kodmässigt, mellan dessa två typer av servlets. Skillnad ligger helt och hållet i serverns konfiguration. Temporära servlets laddas vid behov och ger därmed goda förutsättningar för att spara på resurserna. Servlets som kräver mycket processorkraft för att startas brukar ofta vara permanenta. Exempel på sådan kan vara servlets som kopplar upp sig mot en DBMS. Ytterligare en anledning till att använda sig av permanenta servlets är om kravet på snabb tillgänglighet är stort. 2.4.1.3 Livscykel En servlet körs som en del av den process som webbservern själv kör på. Webbservern är ansvarig för att initiera, anropa och avsluta varje servletinstans. Kommunikationen mellan servern och en servlet sker genom gränssnittet javax.servlet.servlet, vilket i huvudsak definieras genom de tre metoderna init, service och destroy. Init-metoden Varje gång en servlet startas upp anropas dess init-metod. I den här metoden kan servern göra lämpliga inställningar, såsom öppna filer eller skapa kopplingar. Metoden är garanterad att slutföras innan någon annan metod kan anropas. Ett argument, ServletConfig, skickas med till metoden. (ServletConfig består i princip av flera olika initieringsargu- 6

ment för en servlet. Bland annat innehåller den en ServletContext som i sin tur innehåller information om en servlets miljö.) Service-metoden Service-metoden är själva hjärtat i en servlet. Varje förfrågan från en klient resulterar i ett anrop till service-metoden. Metoden tolkar förfrågan och returnerar ett svar till klienten med hjälp av de två parametrarna som skickas med (ServletRequest och ServletResponse). Servlet- Request innehåller information om och från klienten och Servlet- Response är svaret vi konfigurerar till klienten. I korthet kan man säga att service-metodens viktigaste uppgift är att returnera ett svar på klientens förfrågan. (Observera att om en servlet kommunicerar med flera klienter samtidigt måste vi ta hänsyn till trådning, om den t.ex. arbetar mot en databas.) Destroy-metoden Destroy-metoden anropas innan en servlet förstörs. Detta gör det möjligt för en servlet att städa efter sig (stänga öppna filer, stänga uppkoppling mot databaser,...). Servern väntar med att anropa den här metoden tills antingen alla service-anrop är avslutade eller tills någon tidsgräns är uppnådd. Med tanke på det sistnämnda är det viktigt att vara noggrann när vi skriver destroy-metoden, så att inga fel uppstår. För kodexempel för en servlet som returnerar en statisk HTML-sida till en webbläsare hänvisas till bilaga A.5.1. 2.4.1.4 HTTP-hjälpklasser För att använda HTTP-hjälpklasserna är det naturligt att skapa en servlet som ärver från HttpServlet och skriva över någon av eller båda metoderna doget och dopost. HTTP GET och HTTP POST Det är viktigt att implementera doget-metoden så att den är säker och idempotent. Typiska fall när vi bör välja dopost-metoden är när vi vill behandla ett HTML-formulär eller när vi vill skicka över en stor mängd data. (Se A.3 för mer information om HTTP och begreppen säker och idempotent.) Behandlingen av en POST-förfrågan skiljer sig på många sätt från en GET-förfrågan. Eftersom en POST-förfrågan förväntas ändra data på servern måste vi ta hänsyn till att flera klienter kan göra en sådan förfrågan samtidigt. 2.4.1.5 Säkerhetsaspekter På samma sätt som det finns säkerhetsaspekter att tänka på när det gäller en Java applet, finns det också vissa betänkligheter när det gäller servlets. Servlet sandbox En sandbox för en servlet är det område en servlet kan röra sig i. Den bestämmer vad de får uträtta. En servlet kanske inte har tillgång till filsystemet eller nätverket, medan en annan har det. Det är upp till 7

administratören att definiera reglerna. En servlet som har fulla rättigheter kan t.o.m. stänga ner servern genom System.exit(). Access Control Lists (ACLs) Många webbservrar ger oss möjlighet att begränsa åtkomsten till webbsidor och servlets genom en ACL (Access Control List). Det kan vara väldigt viktigt att definiera en ACL, särskilt med tanke på att en servlet kan komma åt och manipulera känslig information. 2.4.1.6 Trådningsaspekter En webbserver kan anropa en servlets service-metod flera gånger samtidigt. Detta gör det viktigt att tänka på trådsäkerhet. Om vi först betraktar init-metoden, så har vi inte några problem. En servlets initmetod anropas endast en gång, när den laddas. Ingen annan metod kan anropas innan init-metoden är slutförd. Om service-metoden använder sig av resurser utanför den egna klassen måste vi noggrant undersöka och ta hänsyn till vad som händer vid multipla anrop. 2.4.2 JSP (JavaServer Pages) JSP låter oss använda servletkod i ett textbaserat dokument. En JSP-sida består av två olika texttyper en statisk del (t.ex. HTML) och en JSPdel, JSP-element (servletkod/javakod[ scriplets ]), som bestämmer det dynamiska innehållet. Med JSP kan vi separera utseendet från den underliggande affärslogiken, så att vi får webbserver- och plattformsoberoende. JSP-specifikationen 3 är en standardiserad utökning av API:n för en Servlet. JSP eller servlets? Enligt Suns J2EE Blueprints 4 ska servlets endast användas som en utökning av webbserver-teknologin. Exempel på servlets kan vara kontrolleringskomponenter som tillhandahåller tjänster som verifiering, databasvalidering etc. (JSP-motorn är egentligen inget mer än en servlet som körs under kontroll av servletmotorn.) Eftersom JSP endast behandlar textuell data måste vi använda oss av servlets när vi vill kommunicera med applets och applikationer. JSP använder vi oss av när vi vill utveckla webbapplikationer som beror på dynamiskt innehåll. Vi bör även använda JSP istället för bl.a. SSI (server-side includes). 2.4.2.1 Arkitektur Meningen med JSP är att erbjuda en deklarativ och presentationscentrerad metod för utveckling av servlets. 3 http://java.sun.com/products/jsp/reference/api/index.html 4 http://java.sun.com/reference/blueprints/ 8

2.4.2.2 Model-View-Controller Processen är uppdelad på två komponenter presentationskomponent och frontkomponent. Presentationskomponenter är JSP-sidor som genererar HTML/XML-svar. Frontkomponenter, controllers, står inte för presentationen utan behandlar istället HTTP-förfrågningar. Frontkomponenterna är ansvariga för att skapa alla bönor och objekt som används av presentationskomponenterna samt att välja, beroende på användarens val, vilken presentationskomponent som ska användas. Frontkomponenter kan vara servlets eller JSP-sidor. Fördelen med den här arkitekturen är att det inte förekommer någon behandlingslogik i själva presentationskomponenten den är endast till för att hämta de objekt och bönor som behövs och sedan plocka fram det dynamiska innehåll som önskas och placera det i det statiska innehållet. (Se figur 2-3.) Figur 2-3 Flödesdiagram för Model-View-Controller design. En klient ställer en fråga till en servlet (Controller), som i sin tur kommunicerar med bönan (Model). När servleten fått datat från bönan anropas en JSP-sida (View) som presenterar resultatet för klienten. 2.4.3 EJB (Enterprise Java Beans) En EJB-komponent är ett byggblock som kan användas fristående eller tillsammans med andra EJB:s, för att köra affärslogik på en J2EEserver. Det finns tre sorters EJB:s session beans, entity beans och messagedriven beans. En av de vanligaste uppgifterna en EJB har är att kommunicera med databaser. Det kan då vara fördelaktigt att använda sig av en entity bean, ty då behöver vi inte skriva någon SQL-kod eller använda JDBC API:n; det gör EJB-containern åt oss. En entity bean representerar en persistent enhet som är stateful (t.ex. bankkonto, person, kund, kan ses som en tupel i en databas). Den representerar bestående data som är lagrad som en tupel i en databastabell. Om klienten avslutar konversationen eller om servern stängs av, garanterar den underliggande servicen att datat i aktuell böna är lagrat. För att representera handlingar eller åtgärder (enstaka eller sessioner) passar det bättre att använda en session bean, som kan vara antingen 9

stateless eller stateful. En session bean är en obestående konversation med en klient. När konversationen är klar försvinner aktuell bean och dess data. En message-driven bean kombinerar egenskaper från en session bean och en JMS (Java Message Service), vilket ger en affärskomponent möjlighet att ta emot JMS-meddelanden asynkront. 2.4.3.1 Specificering av EJB Remote-gränssnittet Remote-gränssnittet, som genereras när bönan placeras ut, är klientens vy av EJB:n. Definitionen av gränssnittet skall göras med Java RMIsyntax, vilken EJB-containern sedan använder för att generera koden. För att läsa om begränsningar och regler för vad som kan definieras i gränssnittet hänvisas till Enterprise JavaBeans Specification 5. Viktigt att nämna är att alla objekt, parametrar, returvärden och undantag som används ska vara giltiga enligt Java to IDL Mapping Specification 6. Remote-gränssnittet ärver från EJBObject och Remote. Se bilaga A.6.1 för kodexempel (Demo.java). 2.4.3.2 Specificering av EJB Home-gränssnittet Home-gränssnittet, som också genereras när bönan placeras ut, för en session bean gör så att containern kan skapa en ny session bean för klienten. På samma sätt som för remote-gränssnittet ska home-gränssnittet deklareras med RMI-syntax. Även här är det containern som implementerar gränssnittet. Home-gränssnittet ärver från EJBHome. Se bilaga A.6.2 för kodexempel (DemoHome.java). 2.4.3.3 Skapandet av EJB-klassen Här kommer själva affärslogiken för applikationen in. Till skillnad från remote- och home-gränssnittet, ska vi här själva skriva koden (genereras alltså inte av containern). Denna klass måste, om vi vill skapa en session bean, implementera SessionBean. Se bilaga A.6.3 för kodexempel (DemoBean.java). 2.4.3.4 Skapande av EJB-jar filen En stor fördel med EJB är möjligheten att skapa paket med affärslogik, som sedan är lätta att distribuera. I princip går skapandet av ett paket till på följande vis: kompilera filerna skapa en utplaceringsbeskrivnings-fil (deployment descriptor) skapa en manifest-fil skapa en jar-fil som innehåller ovanstående placera ut jar-filen på en server 5 http://java.sun.com/products/ejb/docs.html 6 http://java.sun.com/j2se/1.5.0/docs/guide/idl/ 10

2.4.3.5 Klient för en EJB Viktiga punkter som måste finnas med i programmet är följande: etablera JNDI Initial Context (gränssnitt för uppslagningar) hitta home-gränssnittet för bönan med hjälp av JNDI användandet av home-gränssnittet för att instruera containern att skapa en instans av bönan användandet av remote-gränssnittet för att instruera containern att köra bönans metoder Se bilaga A.6.4 för exempel (DemoClient.java). 2.4.4 Övriga J2EE API:er Se bilaga A.7 för nedanstående J2EE API:er. JDBC (Java Database Connectivity) JMS (Java Message Service) JNDI (Java Naming and Directory Interface) JTA (Java Transaction API) JavaMail API JAF (JavaBeans Activation Framework) SAAJ J2EE Connector Architecture JAAS (Java Authentication and Authorization Service) 11

3 Web services Enligt W3C 7 Web Services Architecture group har vi följande definition på web services (fritt översatt): En web services är en applikation, identifierad genom en URI, vars gränssnitt och bindningar är möjliga att definiera, beskriva och finna genom XML, samt är tillgänglig för interaktion med andra applikationer genom XML-baserade meddelanden via ett Internetbaserat protokoll. En web services kräver inte SOAP eller HTTP, däremot behövs en XML-baserad beskrivning såsom t.ex. WSDL. En SOA 8 är ett sätt att designa och bygga löst kopplade lösningar som exponerar affärslogik för andra applikationer genom offentliga gränssnitt. En web services är en SOA med följande restriktioner: gränssnitten måste baseras på något Internetprotokoll (t.ex. HTTP, FTP eller SMTP) meddelanden måste skickas som XML (förutom meddelande-bilagor som får vara binära) Det finns två huvudinriktningar för web services SOAP web services 9 och REST web services 10. (REST står för Representational State Transfer.) SOAP web services För att en web services ska kategoriseras som en SOAP web services krävs det att: meddelanden måste transporteras med SOAP (förutom binära meddelande-bilagor) servicen måste beskrivas med WSDL SOAP web services är den vanligaste formen för web services. Även här finns det två huvudgrenar SOAP RPC web services och dokumentcentrerad SOAP web services 11. (Av dessa två räknas dock inte SOAP RPC som en SOA.) Eftersom SOAP RPC gör om RPC-anrop till SOAP-meddelanden krävs det att den måste beskriva mycket av det underliggande systemet. Detta kan ofta vara väldigt krångligt och skiftande, varför det enligt SOAP 1.2-specifikationerna är valfritt att stödja RPC. REST web services En REST web services är en SOA som är uppbyggd runt vilka resurser som finns. För att en web services ska katogoriseras som en REST web services krävs följande: gränssnittet som används måste beskrivas med hjälp av HTTP meddelanden måste skickas som XML (även om det är tillåtet att i viss utsträckning skicka enkla meddelanden genom URL) servicen måste betraktas som en resurs medan en användare kan betraktas som en resurs 7 http://www.w3.org/tr/2004/note-ws-gloss-20040211/ 8 http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html 9 http://www.w3.org/tr/2003/rec-soap12-part0-20030624/ 10 http://www.xml.com/pub/a/ws/2002/02/20/rest.html 11 http://webservices.xml.com/pub/a/ws/2003/09/02/typeless.html 12

För att testa skalbarhet hos web services har vi valt att använda SOAP RPC web services. Vilken inriktning vi väljer att använda spelar mindre roll resultatmässigt, då vi har en väldigt enkel uppbyggnad av vår web services. 3.1 XML 12 XML, extensible Markup Language, är egentligen inget annat än ren text. Ett XML-dokument används i första hand för att beskriva data och dess egenskaper och inte hur det ska presenteras (som är fallet med HTML). Med XML har vi ett bra sätt att transportera, strukturera och lagra information. Utseendet i ett XML-dokument varierar från fall till fall. Vi bestämmer själva vad taggarna ska heta och innehålla. För att säkerställa att en viss struktur efterföljs kan vi skapa ett DTD (=Document Type Definition) eller ett XML Schema. En viktig fördel med XML är, eftersom det är en textfil, att det är plattforms-, applikations och hårdvaruoberoende. I princip kan man säga att alla XML-dokument är byggda av följande enkla block: elements, tags, attributes, entities, PCDATA och CDATA. Tags används för att märka upp element. En starttag <element_name> märker upp början av ett element, medan taggen </element_name> märker upp slutet av ett element. Attributes står för extra information om elementen. Attribut är alltid placerade inuti elementets starttag och skrivs alltid på formen name/value: <img src= computer.gif /> Entities är variabler som används för att definiera vanlig text. Entityreferenser är referenser till Entities. FÖLJANDE ENTITIES ÄR FÖRDEFINIERADE I XML entity referenser tecken < < > > & & " &apos; Förvisso är de två olika citattecknen och > tillåtna, men det kan vara en bra praxis att byta ut dem ändå. PCDATA, Parsed Character DATA, är texten mellan starttaggen och sluttaggen i ett XML-element. PCDATA är text som kommer att parsas av en parser. Taggar i texten behandlas som taggar och entities kommer att tolkas (expanderas). 12 Exemplen i detta kapitel är med tillåtelse hämtade från http://www.w3schools.com 13

CDATA, Character DATA, är text som inte kommer att parsas av någon parser. Taggar i texten kommer inte behandlas som taggar och entities kommer inte att tolkas (expanderas). 3.1.1 Syntax KODEXEMPEL Rad 1: <?xml version="1.0" encoding="iso-8859-1"?> Rad 2: <note> Rad 3: <to>tove</to> Rad 4: <from>jani</from> Rad 5: <heading>reminder</heading> Rad 6: <body>don't forget me this weekend!</body> Rad 7: </note> FÖRKLARING Första raden är XML-deklarationen. Den definierar vilken XML version som gäller och vilken teckenkodning (character encoding) som används. I vårt exempel rättar dokumentet sig efter XML 1.0 specifikationerna och använder teckenkodningen ISO-8859-1 (Latin-1/West European). Andra raden beskriver rotelementet för dokumentet, dvs. det här är ett note-dokument. Nästkommande fyra rader, rad tre till sex, beskriver fyra underelement till roten (to, from, heading och body). Sista raden säger att här kommer slutet av rotelementet. I XML måste varje element vara slutet, dvs. varje starttagg måste ha en sluttagg (gäller dock ej deklarationstaggen, rad 1, ty den betraktas ej som ett element). Krav finns också på att nästlade element måste vara korrekt nästlade (<b><i>text</i></b>). I varje XML-dokument måste det finnas ett rotelement (i vårt exempel note). Vidare kan varje element bestå av flera element. Viktigt här att påpeka är att ny rad i dokumentet endast representeras med return (line feed), alltså ingen radbrytning (carriage return). (Vill vi skriva kommentarer skriver vi dem på formatet <!-- This is a comment -->) 3.1.2 Element KODEXEMPEL <book> <title>my First XML</title> <prod id="33-657" media="paper"></prod> <chapter>introduction to XML <para>what is HTML</para> <para>what is XML</para> </chapter> </book> FÖRKLARING Elementen kan ha olika innehåll: book har element content, för den innehåller andra element. chapter har mixed content, för den innehåller både text och andra element. 14

para har simple content (eller text content), för den innehåller endast text. prod har empty content, för den innehåller ingen information. Det finns vissa regler man måste följa när man ger namn åt sina element: namn kan innehålla bokstäver, siffror och andra tecken namn får inte börja med siffror eller interpunktionstecken namn får inte börja på med bokstäverna XML (varken stora eller små) namn får inte innehålla blanksteg namn bör inte innehålla tecknet :, för det är reserverat för namngivningsrymder namnen med stora och små bokstäver är olika 3.1.3 Attribut Attribut ger information om elementet, t.ex. <file type="gif">computer.gif</file>. Data kan ofta lagras i attribut eller underelement, men underelement är nog att föredra. En riktlinje för att välja var informationen ska placeras är att försöka ha metadata (data om data) lagrade som attribut, och själva datat lagrat som element. T.ex. om du har flera kapitel-element kan du ha kapitelnumret som attribut, men innehållet som element. Attributvärden i en tag måste inneslutas med citattecken. 3.1.4 Validering Vi betraktar ett XML-dokument med korrekt syntax som Well Formed XML. Om dokumentet även är validerat mot en DTD betraktar vi det som Valid XML. (Valid XML är Well Formed XML som är anpassat efter reglerna i ett DTD.) KODEXEMPEL <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE note SYSTEM "InternalNote.dtd"> <note> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don't forget me this weekend!</body> </note> Här är DTD:n deklarerad som en extern fil. I DTD-filen har vi deklarerat vilka element som får/måste vara med och hur de ska se ut. (Ett XML Schema är ett XML-baserat alternativ till DTD.) 3.1.5 Namnrymd Eftersom elementnamnen inte är fixa finns det risk för att namnkrockar sker. Vi kan då specificera vilken namnrymd som används för att undvika krockar. För att kunna använda flera namnrymder kan vi använda attribut för att bestämma vilken namnrymd som används. Attributet har formen xmlns:namespace-prefix="namnrymd" 15

KODEXEMPEL <h:table xmlns:h="http://www.w3.org/tr/html4/"> <h:tr> <h:td>apples</h:td> <h:td>bananas</h:td> </h:tr> </h:table> Om man definierar en standarnamnrymd slipper man använda prefixet i alla underelement. Det har då formen: <element xmlns="namnrymd"> 3.1.6 CDATA All text i ett XML dokument kommer att parsas av en parser, utom text i en CDATA-sektion. För att en text ska parsas korrekt är det viktigt att vissa tecken inte förekommer. Dessa tecken måste bytas ut mot respektive entity reference (enhet). Om vår text innehåller många ogiltiga tecken kan det vara bra att använda en CDATA-sektion. En sådan sektion börjar med <![CDATA[ och slutar med ]]> KODEXEMPEL <script> <![CDATA[ function matchwo(a,b) { if (a < b && a < 0) then { return 1 } else { return 0 } } ]]> </script> Observera att en CDATA-sektion inte kan innehålla en annan CDATAsektion. 3.1.7 DTD Syftet med DTD, Document Type Definition, är att definiera hur ett godkänt XML-dokument ska se ut. Det definierar dokumentets struktur med en lista av godkända element. Antingen kan vi deklarera en DTD internt i ett XML-dokument eller som en extern referens (då ligger deklarationen i en separat fil). Om vi väljer att deklarera internt ska syntaxen vara <!DOCTYPE root-element [element-declarations]> och om vi väljer externt <!DOCTYPE root-element SYSTEM "filename"> 16

KODEXEMPEL (INTERN DEKLARATION) Rad 1: <?xml version="1.0"?> Rad 2: <!DOCTYPE note [ Rad 3: <!ELEMENT note (to,from,heading,body)> Rad 4: <!ELEMENT to (#PCDATA)> Rad 5: <!ELEMENT from (#PCDATA)> Rad 6: <!ELEMENT heading (#PCDATA)> Rad 7: <!ELEMENT body (#PCDATA)> Rad 8: ]> Rad 9: <note> Rad 10: <to>tove</to> Rad 11: <from>jani</from> Rad 12: <heading>reminder</heading> Rad 13: <body>don't forget me this weekend</body> Rad 14: </note>!doctype note på rad 2 definierar det här dokumentet som ett dokument av typen note. På rad 3,!ELEMENT note, deklareras att noteelementet har fyra underelement; to, from, heading och body. De nästkommande fyra raderna, fyra till sju, definierar vilken typ respektive underelement har; #PCDATA. KODEXEMPEL (EXTERN DEKLARATION) <?xml version="1.0"?> <!DOCTYPE note SYSTEM "note.dtd"> <note> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don't forget me this weekend!</body> </note> NOTE.DTD <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> Med hjälp av DTD kan våra XML-filer ha en beskrivning av dess format. Ytterligare två fördelar med att ha en DTD är att flera personer kan enas om en standard samt att man lätt kan validera en XML-fil. För noggrannare genomgång av DTD hänvisas till bilaga A.1.1. 3.1.8 XML Schema XML Schema, som även benämns XML Schema Definition (XSD), är ett XML-baserat alternativ till DTD. Schemat beskriver strukturen i ett XML-dokument och definierar alltså vilka element och attribut som kan förekomma, vilka element som är underelement och hur många sådana som får förekomma, vilka datatyper som är godkända, osv. Faktum är att XML-schema kan ses som efterträdare till DTD, detta bl.a. tack vare den goda möjligheten att kunna utökas för framtida behov och för sitt stöd för datatyper och namnrymder. Några av fördelarna med det goda stödet för datatyper är att det är lättare att validera dokument, arbeta mot databaser, definiera begränsningar samt konvertera data mellan olika 17

datatyper. Ytterligare en fördel med att XML-schema är skrivet i XML är att vi kan använda en XML-parser för att parsa våra schema-filer, vi kan manipulera vårt schema med XML DOM (Document Object Model) samt vi kan transformera vårt schema med XSLT (extensible Stylesheet Language Transformations, vilket är ett språk för att transformera XML-dokument till andra XML-dokument). Rotelementet i varje XML-schema är schema-elementet, vilket också kan innehålla en del attribut. KODEXEMPEL (XSD-DOKUMENT) <?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" targetnamespace="http://www.w3schools.com" xmlns="http://www.w3schools.com" elementformdefault="qualified">...... </xs:schema> FÖRKLARING xmlns:xs= http://www.w3.org/2001/xmlschema indikerar att elementen och datatyperna som används i det här schemat (schema, element, complextype, sequence, string, boolean, etc.) kommer från namnrymden http://www.w3.org/2001/xmlschema. Det säger också att elementen och datatyperna som kommer därifrån ska ha prefixet xs:. targetnamespace= http://www.w3schools.com indikerar att elementen som är definierade av det här schemat (note, to, from, heading, body) kommer från namnrymden http://www.w3schools.com. xmlns= http://www.w3schools.com indikerar att standarnamnrymden är http://www.w3schools.com. elementformdefault="qualified" indikerar att varje element som används i denna instans av XML-dokumentet som var deklarerat i schemat måste vara godkänt i den namnrymden. SCHEMAREFERENS I ETT XML-DOKUMENT <?xml version="1.0"?> <note xmlns="http://www.w3schools.com" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://www.w3schools.com note.xsd"> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don't forget me this weekend!</body> </note> xmlns= http://www.w3schools.com specificerar deklarationen av standardnamnrymden. Deklarationen låter schema-validatorn veta att det här XML-dokumentet är deklararat i namnrymden http://www.w3schools.com. xmlns:xsi= http://www.w3.org/2001/xmlschema-instance beskriver var XML-schema-instansen finns. 18

xsi:schemalocation=http://www.w3schools.com note.xsd kan användas när föregående punkt är angiven. Uttrycket anger vilken namnrymd som ska användas och var XML-schemat för den namnrymden finns (note.xsd). För noggrannare genomgång av XML-schema hänvisas till bilaga A.1.2 3.2 SOAP (Simple Object Access Protocol) SOAP är ett enkelt XML-baserat kommunikationsprotokoll som låter applikationer utbyta information över HTTP. Till exempel kan vi, med hjälp av SOAP, få tillgång till en web services. Eftersom protokollet är XML-baserat är det expanderbart, språk- och plattformsoberoende. (SOAP kommer att utvecklas som en W3C 13 -standard.) Se figur 3-1 för uppbyggnad av ett SOAP-meddelande. 3.2.1 Syntax Ett SOAP-meddelande är ett vanligt XML-dokumnet som innehåller följande element (se figur 3-1): ett envelope-element som identifierar XML dokumentet som ett SOAP-meddelande (eventuellt) ett header-element som innehåller information om huvudet ett body-element som innehåller anrops- och svarsinformation (eventuellt) ett fault-element som tillhandahåller information om fel som kan uppstå vid behandling av meddelandet Alla element ovan är deklarerade i standardnamnrymden för SOAP envelope http://www.w3.org/2001/12/soap-envelope. Deklaration finns även för teckenkodning och datatyper http://www.w3.org/2001/12/soap-encoding. Varje SOAP-meddelande måste använda både SOAP Envelope- och SOAP Encoding-namnrymden, men får inte använda vare sig någon DTD-referens eller XML Processing Instruction. För exempel på ett enkelt SOAP-meddelande hänvisas till bilaga A.8.1. 3.2.2 Envelope-element Det obligatoriska envelope-elementet är rotelementet i ett SOAPmeddelande (se figur 3-1). Detta element definierar XML-dokumentet som ett SOAP-meddelande. (Observera användandet av xmlns:soap namnrymd värdet ska alltid vara http://www.w3.org/2001/12/soapenvelope. Om en annan namnrymd används ska applikationen generera ett felmeddelande och sedan bortse från meddelandet.) Attributet encodingstyle används för att definiera vilka datatyper som används i dokumentet. Attributet kan förekomma i vilket SOAP-element som helst och gäller då i hela innehållet för det elementet och alla dess underelement. 13 http://www.w3.org 19

EXEMPEL <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soapencoding">... Message information goes here... </soap:envelope> 3.2.3 Header-element Det frivilliga header-elementet innehåller informationshuvudet (se figur 3-1). Informationen är applikationsspecifik, t.ex. verifiering, betalning..., för SOAP-meddelandet. Om header-elementet existerar måste det vara första underelementet till envelope-elementet. Observera att alla direkta underelement till header-element måste vara namnrymdskvalificerade. EXEMPEL <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soapencoding"> <soap:header> <m:trans xmlns:m="http://www.w3schools.com/transaction/" soap:mustunderstand="1">234</m:trans> </soap:header>...... </soap:envelope> Attributen i SOAP-huvudet definierar hur mottagaren ska behandla SOAP-meddelandet. SOAP definierar tre attribut i standardnamnrymden (http://www.w3.org/2001/12/soap-envelope) actor, mustunderstand och encodingstyle. Actor används för att adressera header-elementet till en viss mottagare (soap:actor="uri"). mustunderstand används för att indikera huruvida en information i huvudet är obligatoriskt eller frivilligt att behandla för mottagaren. Om det står mustunderstand= 1 i ett underelement till header-elementet, då måste mottagaren som behandlar header förstå det elementet, om inte måste behandlingen avbrytas. Syntaxen är soap:mustunderstand="0 1" 3.2.4 Body-element Det obligatoriska body-elementet innehåller det faktiska meddelandet (se figur 3-1). Direkta underelement kan vara namnrymdskvalificerade. SOAP definierar ett element inuti body-elementet i sin standardnamnrymd fault-elementet, vilket används för att indikera fel. 20

EXEMPEL <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soapencoding"> <soap:body> <m:getprice xmlns:m="http://www.w3schools.com/prices"> <m:item>apples</m:item> </m:getprice> </soap:body> </soap:envelope> (Observera att elementen m:getprice och m:item är applikationsspecifika. De är inte en del av SOAP-standarden.) En SOAP-respons skulle kunna se ut på följande sätt: <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soapencoding"> <soap:body> <m:getpriceresponse xmlns:m="http://www.w3schools.com/prices"> <m:price>1.90</m:price> </m:getpriceresponse> </soap:body> </soap:envelope> 3.2.5 Fault-element Det är valfritt att ha med fault-elementet (se figur 3-1). (Om det finns med måste det vara ett underelement till body-elementet och får endast förekomma en gång i ett SOAP-meddelande.) Ett felmeddelande från ett SOAP-meddelande är lagrat inuti fault-elementet. FAULT-ELEMENTET HAR FÖLJANDE UNDERELEMENT Underelement <faultcode> <faultstring> <faultactor> <detail> Beskrivning en kod för att identifiera felet en läsbar förklaring om felet information om vem som orsakade felet applikationsspecifik felinformation, relaterad till body-elementet 21

NEDAN DEFINIERADE FAULTCODE-VÄRDEN MÅSTE ANVÄNDAS I FAULTCODE- ELEMENTET VID BESKRIVNING AV FEL Fel VersionMismatch MustUnderstand Client Server Beskrivning felaktig namnrymd för envelopeelementet funnen kunde inte förstå ett direkt underelement till header-elementet med attributet mustunderstand satt till värdet 1 meddelandet var felaktigt konstruerat eller innehöll felaktig information problem med servern uppstod, det gick inte att slutföra meddelandet Figur 3-1 Beskrivning av hur ett SOAP-meddelande är uppbyggt. Envelope-element definierar XML-dokumentet som ett SOAP-meddelande. Det applikationsspecifika header-elementet innehåller informationshuvudet och body-elementet innehåller det faktiska meddelandet. Inuti body-elementet är det valfria fault-elementet placerat. Sist i SOAP-meddelanden kan det ligga en bilaga (SOAP Attachment), vilket vi inte går in på i vårt arbete. 3.2.6 HTTP-binding Kort om HTTP-protokoll (se bilaga A.3 för mer information) HTTP kommunicerar över TCP/IP. En HTTP-klient kopplar upp sig mot en HTTP-server m.h.a TCP. När uppkopplingen är gjord kan klienten sända en HTTP-förfrågan till servern: POST /item HTTP/1.1 Host: 189.123.345.239 Content-Type: text/plain Content-Length: 200 22

Servern behandlar sedan förfrågan och skickar tillbaka en HTTPrespons till klienten. Responsen innehåller information om utfallet av behandlingen. HTTP-respons (allt gick bra): 200 OK Content-Type: text/plain Content-Length: 200 HTTP-respons (något blev fel): 400 Bad Request Content-Length: 0 En SOAP-metod är en HTTP-förfrågan/respons som rättar sig efter SOAP:s teckenkodningsregler. Vi kan till och med säga att HTTP + XML = SOAP. En SOAP-förfrågan kan vara en HTTP POST- eller en HTTP GET-förfrågan. En HTTP POST-förfrågan specificerar minst två delar i HTTP-huvudet Content-Type och Content-Length. Content- Type delen i huvudet för en SOAP-förfrågan eller respons definierar vilken MIME-typ och teckenkodning (valfritt) som används i XMLkroppen. Syntaxen är: Content-Type: MIMEType; charset=character-encoding EXEMPEL POST /item HTTP/1.1 Content-Type: application/soap+xml; charset=utf-8 Content-Length delen i huvudet för en SOAP-förfrågan eller SOAPrespons specificerar antalet bytes i förfrågan- eller responskroppen. Syntaxen är Content-Length: bytes EXEMPEL POST /item HTTP/1.1 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 250 För exempel på en SOAP-förfrågan hänvisas till bilaga A.8.2. För exempel på en SOAP-respons hänvisas till bilaga A.8.3. 3.3 WSDL (Web Services Description Language) WSDL är ett XML-baserat språk för att beskriva web services och hur man kan använda dem. Det specificerar platsen för servicen samt vilka operationer/metoder som finns att tillgå. 23

DOKUMENTET BYGGS UPP AV FÖLJANDE Element <porttype> <message> <types> <binding> Definition operationerna som utförs av web services meddelandena som används i web services datatyperna som används av web services kommunikationsprotokollen som används av web services Message <message>-elementet definierar dataelementen för en operation. Det kan bestå av en eller flera delar, där delarna kan betraktas som parametrarna i ett metodanrop. Types <types> definierar datatypen som web services använder sig av. Datatyperna är hämtade från XML-schema-syntax, vilket gör det hela plattformsoberoende. Ports Elementet <porttype> är det viktigaste WSDL-elementet. Det definierar själva web services, operationerna som kan tillgås och vilka message-element som används. Elementet kan ses som en modul eller klass. Operationstyper Den vanligaste operationstypen är request-response, men WSDL definierar fyra typer. FYRA WSDL-OPERATIONSTYPER one-way Typ request-response solicit-response notification Definition operationen kan ta emot ett meddelande, men returnerar inget svar operationen tar emot en förfrågan och ger en respons operationen kan skicka en förfrågan och kommer då vänta på en respons operationen kan skicka ett meddelande, men väntar inte på något svar För exempel på one-way operation, se bilaga A.9.1. För exempel på request-response operation, se bilaga A.9.2. Binding <binding> definierar message-formatet och protokolldetaljerna för varje port. För exempel på Binding To SOAP (förfrågnings/respons-operation), se bilaga A.9.3. 24