Microsoft har placerat webbtjänster som ett centralt fokus för .NET, och dess rivaler inklusive Google, IBM och Sun lägger lika stor vikt vid dem. I den här artikeln kommer jag att undersöka vad webbtjänster är, vad de är användbara för och varför du kanske vill bygga dem. Det första problemet är ett av nomenklaturen – webbtjänster riskerar att drunkna i ett hav av förkortningar, som XML, SOAP och WSDL. Jag tillbringade lite tid med att fråga de mest populära sökmotorerna efter termerna jag kommer att använda i den här artikeln, och när jag gick in på ”Web Services” blev jag ganska skakad när Google gav 442 miljoner träffar. Som jämförelse gav MSN Search bara 241 miljoner träffar och Ask.com svaga 166 miljoner. Jag har inte hunnit recensera alla dessa träffar, men ni kan se hur hett det här ämnet har blivit.
Innan vi tittar på hur man bygger en webbtjänst måste vi förstå vad en är. World Wide Web Consortium (W3C) definierar en webbtjänst som ”en mjukvaruapplikation som identifieras av en URI, vars gränssnitt och bindningar kan definieras, beskrivas och upptäckas som XML-artefakter”. Definitionen förklarar sedan att en webbtjänst interagerar med klienter genom att skicka XML-baserade meddelanden, utbytta via internetbaserade protokoll. Men vad betyder det egentligen? Tja, först står det att en webbtjänst bara är en applikation som klienter kan komma åt genom att skriva en URI (t.ex http://host/webservice/service.asmx) till en webbläsare, antingen över internet eller via ett internt företagsintranät. En webbtjänsts klient kommunicerar med tjänsten via XML-baserade meddelanden snarare än genom något binärt protokoll som är specifikt för den applikationen, vilket är fallet med tidigare system. Slutligen betyder ”internetprotokoll”-delen av definitionen att dessa XML-meddelanden skickas med HTTP. I själva verket förvandlar detta HTTP till ett transportprotokoll som passerar brandvägg på högre nivå (Microsofts Jesper Johanssen beskriver detta som att det omvandlas till Universal Firewall Bypass Protocol).
Webbtjänsternas funktioner kan inte stödjas fullt ut med endast HTTP, även om du kan anropa tjänsten i första hand med ett HTTP Post-meddelande. För större flexibilitet har ett extra protokoll kallat SOAP (Simple Object Access Protocol) utvecklats, som används för att skicka meddelanden programmatiskt mellan Web Services och deras klienter. För att göra det möjligt för kunder och tjänster att kommunicera effektivt definieras webbtjänster formellt med ett beskrivningsspråk som kallas Web Services Description Language, eller WSDL.
Och utöver allt detta finns Universal Description, Discovery and Integration (UDDI), som tillhandahåller katalogtjänster som gör det möjligt för företag att både registrera nya webbtjänster och söka efter befintliga. UDDI var en bra idé och användbar när man skulle få igång webbtjänstkonceptet, men det används inte mycket idag. Om du behöver använda en webbtjänst vet du antingen var den redan finns (och behöver därför inte UDDI) eller så kommer du att använda en sökmotor som Google för att söka efter den. Till och med Microsofts eget UDDI-register på http://uddi.microsoft.com har varit stängt sedan början av detta år (se http://tinyurl.com/pehwl för mer information), och URL:en omdirigerar nu till http:// tinyurl.com/76wx6.
Web Services vs RPC
Vid första anblicken kan webbtjänster tyckas vara bara en ny typ av Remote Procedure Call (RPC), där en klient ber en server om något och får det i retur. Även om det verkligen finns vissa likheter, finns det också några viktiga skillnader:
