Op congressen, feestjes en partijen is één onderwerp nog populairder dan Alexander en Maxima, de webservice. Tijdens bijvoorbeeld het grote XML One congres in Londen trok het onderwerp volle zalen.
IBM, Microsoft, Sun en vele andere leveranciers hebben besloten dat dit de technologie voor de komende jaren is. En misschien is al deze aandacht ook wel terecht, want webservices hebben veel te bieden. Maar laten we realistisch zijn, we zitten nog in de ‘hypefase’. Dat wil zeggen, alles is rozengeur en maneschijn en we bekijken alles door een roze bril. Wat de problemen en nadelen gaan worden, daar wordt nog niet over gesproken, en dat is jammer, want ze zijn wel te voorspellen.
Wat is eigenlijk een webservice? Er bestaat helaas nog geen algemeen geaccepteerde definitie, maar het is zoiets als een stuk code (misschien een component) dat direct aanroepbaar is over het internet. Neem als voorbeeld een website om er telefoonnummers in op te zoeken. Wordt in een klassieke internet-omgeving bij deze website een telefoonnummer opgevraagd, dan krijgen we een opgemaakte html-pagina terug waarin ergens dat telefoonnummer verstopt is. Deze pagina is een eindproduct, het wordt binnen een browser aan een menselijke eindgebruiker getoond. Indien de consument van het telefoonnummer echter geen gebruiker maar een applicatie is, dan is het lastig dat het antwoord in een html-pagina verpakt zit. Alle lay-outspecificaties moeten dan eerst verwijderd worden voordat het telefoonnummer is te bewerken. Het leven zou veel makkelijker zijn als direct op die website een component is aan te roepen die het telefoonnummer teruggeeft. Dus op een vergelijkbare wijze als het aanroepen van een component via Java RMI of COM+. Zo roepen we een webservice over het internet aan.
Om webservices aan te roepen over http is een speciaal protocol ontworpen genaamd Simple Object Access Protocol. Soap is een XML-taal waarmee aanroepparameters naar de webservice toegestuurd en antwoorden teruggestuurd worden. Soap is simpelweg een standaard voor het activeren van webservices over het internet.
Maar Soap werkt alleen als bekend is waar de webservice zich bevindt. Voor het dynamisch aanroepen van een webservice bestaat een additionele standaard; Universal Description, Discovery, and Integration. De basis van Uddi is een directory op het internet waar iedereen zijn webservices bekend kan maken. Consumenten kunnen diezelfde directory raadplegen om webservices dynamisch te zoeken.
Soap en Uddi zijn als standaarden zeer succesvol. Veel organisaties hebben zich reeds aangesloten. Microsoft en Sun zijn zelfs al verder gegaan. Sun is bezig met technologie om zogenaamde ‘smart’ webservices te bouwen. Dit zijn context-afhankelijke webservices. Afhankelijk van wie u bent, waar u zich bevindt en met wat voor apparaat u de webservice benadert, zal de webservice zich anders gedragen. De webservice zal zich aanpassen aan de situatie. Microsoft heeft recentelijk Hailstorm aangekondigd, een verzameling horizontale webservices; zoals een agenda. Bij het maken van een afspraak bijvoorbeeld, wordt die in de agenda-webservice van Microsoft opgeslagen en is daarna vanuit elk soort apparaat (pc, laptop, pda of mobiele telefoon) en vanuit elke plek op deze planeet te benaderen.
Puur naar de technologie kijkend ziet dit er allemaal interessant uit. Maar, zoals reeds vermeld, de problemen en nadelen zijn eenvoudig te voorspellen. Om er enkele te noemen: netwerkverkeer en beveiliging.
Het eerste nadeel zal te maken hebben met de hoeveelheid netwerkverkeer. Technisch is het eenvoudig om bestaande componenten in te pakken en toegankelijk te maken als webservices. Echter, bij de ontwikkeling van deze oude componenten is men ervan uitgegaan dat ze via een snel ‘local area network’ benaderd zouden worden. Indien we diezelfde componenten over het veel langzamere internet zullen benaderen, zal het netwerkverkeer zeer inefficiënt zijn. Om dit probleem te voorkomen moeten er groepen van componenten tot één webservice gebundeld worden, om zodoende het netwerkverkeer te minimaliseren. Hoe is de beschikbaarheid van een applicatie te garanderen als zij gebruik maakt van een externe webservice? Van die externe webservice is niet te verwachten dat deze dezelfde beschikbaarheidniveaus hebben als interne componenten. En hoe zal het met de schaalbaarheid staan?
Een ander probleem vormt de beveiliging. De oude componenten waren beveiligd tegen verkeerd gebruik vanuit de organisatie. Maar zijn ze ook veilig genoeg om door de buitenwereld gebruikt te worden? Daar mogen de beveiligingsexperts zich de komende jaren eens over buigen.
Het werken met transacties wordt ook een uitdaging. Stel dat ik vanuit mijn applicatie gegevens opsla in twee onafhankelijke webservices. Hoe krijg ik het voor elkaar dat beide opdrachten uitgevoerd worden of allebei niet? Met andere woorden, hoe gaan we het begrip atomaire transactie garanderen in een wereld van webservices?
Kortom, webservices hebben veel te bieden. Maar we zullen de ontnuchteringfase wel spoedig gaan meemaken, waarschijnlijk al in 2002. Wilt u gebruik maken van webservices of wilt u uw eigen code als webservice toegankelijk maken, doe dit dan rustig aan. We staan nog aan het begin van deze technologie – en er zijn nog vele hordes te nemen.
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken. Hij is gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
