Hoewel webdiensten vaak worden gezien als middel om gedistribueerde applicaties simpel aan elkaar te knopen, zijn ze veel meer dan dat. Hun volledig elektronisch gedocumenteerde interface zorgt ervoor dat je het binnenhalen en aankoppelen van een externe dienst grotendeels kan automatiseren.
Bij webdiensten denk je al gauw aan middleware om gedistribueerde applicaties aan elkaar te knopen. Het gaat echter om meer dan alleen een web-gebaseerde variant van rpc (Remote Procedure Call). Web services zijn gebouwd op het web-protocol (http) en gebruiken xml om berichten uit te wisselen. Maar ook het formaat van die berichten zelf is weer vastgelegd in een xml-document. Omdat de interface op die manier automatisch door de software kan worden ingelezen, wordt het aankoppelen van een externe webdiensten vanuit een ontwikkelomgeving heel gemakkelijk.
Nog interessanter is dat computersystemen dit aankoppelen ook helemaal zelfstandig kunnen doen. Die automatisering is ook nog eens flexibel; via discovery servers worden beschikbare web services ‘geadverteerd'. Concreet zou dit kunnen betekenen dat een inkoopmanager op zijn desktop een andere toeleverancier selecteert, waarna die automatisch op het erp-systeem wordt aangesloten. Deze technologie is bijvoorbeeld onderliggend aan de bpm 2.0 visie (business process management) van Jan Baan, waarover Computable al eerder publiceerde.
Cloud computing
Hoewel webdiensten vaak onderdeel zijn van gesloten ketens – denk aan de supply chain en andere onderdelen van de waardeketen – zijn er ook min of meer publieke diensten op internet beschikbaar. Amazon is daar een goed voorbeeld van. Die online-boekhandel is ook aanbieder van cloud computing. Het bedrijf biedt onder andere EC2 (Elastic Compute Cloud), S3 (Simple Storage Service) en AAWS (Amazon Associates Web Service).
Die eerste twee zijn respectievelijk cloud computing en cloud storage. Daarvoor wordt gebruik gemaakt van virtuele machines op basis van virtualisatiesoftware Xen en van virtuele data-containers. Deze diensten worden met name gebruikt door jonge, kleine bedrijven (startups) die dan niet hoeven te investeren in een eigen infrastructuur. Op die manier kunnen ondernemers met meer ideeën dan geld meegroeien met hun succes.
AAWS biedt toegang tot het merendeel van de functionaliteit van de webwinkel waarmee Amazon zelf groot is geworden. Bijna alle mogelijkheden zijn ook als webdienst beschikbaar: van productinformatie en elektronische winkelwagentje tot aanbiedingen van verkopers en verlanglijstjes van bezoekers. Programmeurs kunnen daarop aanhaken om hun eigen winkel te creëren of die functionaliteit op een andere manier in hun eigen website te verwerken.
Al die mogelijkheden vertalen zich wel naar een behoorlijk complexe interface. Voordat je met AAWS aan de slag kunt, moet je je eerst door een developer guide van bijna zeshonderd pagina's heen worstelen. Deelnemen kost in dit geval niets, maar levert via het Amazon Associates programma juist geld op.
Kleine en grote webdiensten
Webdiensten zijn in het algemeen op twee manieren te benaderen. Rest (Representational State Transfer) is het gemakkelijkst. Informatie wordt opgevraagd door gewoon in de browser een url in te typen. Daarbij geef je de parameters direct door (via get of post). Wat er terugkomt, hoeft dan niet noodzakelijk in xml-formaat te zijn. Deze methode heeft de voorkeur voor relatief eenvoudige toepassingen.
De zogenaamde Big Web Services kun je daarentegen niet zomaar vanuit je browser benaderen, maar moet je via een xml library aanroepen. Daarbij stuur je je verzoek in een soap envelope (Simple Object Access Protocol) naar de webdienst toe. In dit geval komt er altijd een xml-document met een soap header eromheen terug. Daarnaast zijn er verschillende uitbreidingen om deze transacties te beveiligen.
Xml is in dit geval een prima (leesbaar) formaat voor het uitwisselen van een beperkte hoeveelheid gegevens. Het sluit dan ook goed aan bij het web, waar informatie in het algemeen georganiseerd is in relatief kleine pagina's. Worden via een webdienst grotere hoeveelheden gegevens overgezet, dan wordt xml met die enorme hoeveelheid tags al gauw erg inefficiënt. In dat geval kan, indien de aanbieder van een webdienst dat faciliteert, beter worden gewerkt met json (JavaScript Object Notation). Dat formaat is ook gewoon leesbaar, maar specifiek ontwikkeld voor het overzetten van eenvoudige datastructuren.
Handwerk en fouten
Hoewel de hier beschreven manier van werken uniform is voor alle webdiensten, is de inhoud van de verzoeken en antwoorden natuurlijk specifiek voor de betreffende dienst. Het formaat van de parameters, de velden en de data is vastgelegd in een wsdl-document (Web Services Description Language) en een bijbehorend Schema.
Omdat beide zelf ook weer in xml-formaat zijn geschreven, kan een software-toepassing ze verwerken. Op die manier kan de interface van een webdienst automatisch beschikbaar worden gemaakt in een software-ontwikkelomgeving. Dat gebeurt bijvoorbeeld door het genereren van datastructuren (classes) en functies (methoden) in een soap framework. Hoewel je in principe alle queries zou kunnen doen op basis van Rest, is het gebruik van een soap toolkit aan te raden. Dat scheelt gewoon een heleboel handwerk en fouten.
Sowieso loont het de moeite om vantevoren op internet te zoeken naar wat er voor een bepaalde webdienst verkrijgbaar is. In sommige gevallen is een open source library beschikbaar die niet alleen toegang tot de webdienst zelf biedt, maar die ook aanvullende functionaliteit levert.
Output ook automatiseren
Behalve het vraag- en antwoordspel met de webdienst is ook de vormgeving van de output nog te automatiseren. Omdat het formaat van de antwoorden in een ondubbelzinnig xml-formaat is vastgelegd, kun je een specificatie opstellen voor de vertaling naar html. Daarvoor gebruik je dan xsl (eXtensible Stylesheet Language). Zo'n stylesheet fungeert weer als input voor de xslt-tool (xsl Transformations, die de daadwerkelijke conversie van xml naar html voor zijn rekening neemt.
En zelfs dat hoef je in sommige gevallen niet eens meer zelf te doen. Door de url van een stylesheet aan Amazon door te geven, krijg je het antwoord automatisch in het juiste formaat terug. Op die manier kun je via een Rest-verzoek niet alleen html- of xml-code laten genereren, maar ook heel andere formaten.
Het web als platform
Webdiensten worden vaak gezien als de opvolger van portlets en widgets (respectievelijk interface-plugins voor in webportals en kleine interface-componenten voor op pc's). Waar web services hun functionaliteit op het niveau van middleware en ontwikkelomgevingen (integrated development environments) bieden, doen die laatste twee dat op het niveau van de gebruikersinterface. Als je bijvoorbeeld beurskoersen op je website zou willen aanbieden, dan kun je gebruik maken van kant-en-klare widgets van Yahoo! die direct in de html-code van een webpagina zijn op te nemen. De ontwerper stelt wat parameters in en de benodigde informatie wordt via JavaScript binnengehaald. De advertenties van Google AdSense en de statistieken van Google Analytics werken op dezelfde manier.
Hoewel webdiensten de portal-bouwer veel meer functionaliteit bieden, hebben widgets het voordeel dat de aanbieder van een dienst veel vrijer is in het aanpassen daarvan. Wordt de interface van een webdienst veranderd, dan moet de programmeur opwaarderen naar een nieuwe versie. Wat dat betreft hebben webdiensten alle nadelen van de klassieke api (Application Programming Interface).
De volgende generatie webtoepassingen (web 2.0) levert veel meer flexibiliteit in de manier waarop persoonlijke, sociale en ‘collaborative' functionaliteit gecombineerd wordt ingezet. Deze zogenaamde mashups bouwen voort op webdiensten, maar dan op het niveau van eindgebruikers. JavaScript en Ajax (Asynchronous JavaScript And Xml) spelen daarbij een essentiële rol. Het web fungeert dan alleen nog als platform voor applicaties.
Geen garanties
Hoewel webdiensten het heel makkelijk maken om allerlei informatie bij elkaar te brengen in een nieuwe webapplicatie, kleven er ook belangrijke nadelen aan. Op dit moment zijn webdiensten als technologie wel bruikbaar, maar als dienst vaak nog niet. Online aanbieders hebben meestal niet meer dan een inspanningsverplichting.
Tekenend is de beschikbaarheid van SaaS (Software-as-a-Service) en andere online applicaties: ze liggen er soms een paar dagen per jaar uit. Salesforce.com en de dienst Internetbankieren van de Postbank hebben wat dat betreft inmiddels een slechte naam opgebouwd. Analisten waarschuwen dan ook dat de huidige online diensten voor bijvoorbeeld storage, backup en cloud computing niet bruikbaar zijn voor zakelijk gebruik. Wat heb je aan een backup als je er niet bij kunt als je 'm nodig hebt? En wat doe je als tweehonderd medewerkers een of twee dagen niet bij hun klantgegevens kunnen?
Je loopt dus een risico als je zelf applicaties bouwt waarbij meerdere externe webdiensten in een keten worden ingezet. Jouw applicatie loopt dan het gevaar elke maand wel een dag niet beschikbaar zijn. Ook met betrekking tot de beveiliging vallen er meestal geen harde garanties te geven voor webdiensten.
Een ander aspect is de onderlinge integratie van verschillende online diensten. Nu moet je bijvoorbeeld elke keer je elektronische bankafschriften downloaden en weer uploaden naar een online boekhoudpakket. Bijkomend probleem is de aanmelding die je of je applicatie elke keer én voor elk van de diverse diensten moet doen. In de toekomst zal vaker gewerkt worden met faciliteiten voor single sign-on (sso), zoals Yahoo! die bijvoorbeeld aanbiedt.
