Wat krijg je als je componenten en het internet kruist? Inderdaad, een van de populairste onderwerpen van vandaag: webservices. Iedereen heeft het over Soap (Simple Object Access Protocol), Uddi (Universal Description, Discovery, and Integration) en Wsdl (Web Services Description Language). Samen vormen ze het fundament voor webservices. Maar met standaarden alleen kun je geen applicaties bouwen. De vraag is dus wat de status is van de software waarmee we webservices kunnen implementeren. Het antwoord is: We staan nog aan het prille begin.
De informele definitie van webservice is: een component die via het internet aanroepbaar is en gebaseerd is op de bovengenoemde standaarden. Velen zien webservices als het wondermiddel voor alles, van ‘business-to-business’ applicatie-integratie tot likdoorns. In een ‘whitepaper’ concludeert een leverancier zelfs het volgende: ‘De wijze waarop bedrijven over hun applicaties en over hun business denken, zal door webservices opnieuw gedefinieerd en veranderd worden.’ Een veelbelovende bewering, maar zijn we al zover?
Soap, Uddi en Wsdl zijn alledrie middleware-standaarden. De term middleware was wat populairder in het client/server-tijdperk, maar kan weer uit de kast gehaald worden. Middleware is de software waarmee applicaties over een netwerk met elkaar communiceren. Soap is een op XML gebaseerd protocol waarmee we webservices kunnen aanroepen. Uddi is een ‘directory service’. In deze directory kunnen we softwarematig webservices opzoeken en vervolgens via Soap aanroepen. Uddi maakt het mogelijk dynamische koppelingen te realiseren. Indien we webservices via Uddi aanroepbaar willen maken, moeten we ze wel eerst bekend maken en daar gebruiken we de XML-taal genaamd Wsdl voor.
Een protocol als Soap verhult vele technische specificaties van de aan te roepen webservice. We zien niet in welke programmeertaal ze geschreven is, of het een Corba, Com of Java-component is, via welke netwerkprotocollen we ze moeten aanroepen en op welk platform ze draait. Dit verhullen van technische zaken is typisch de taak van een middlewareproduct.
Uiteraard kunnen we een Java- of Visual Basic-programma ontwikkelen waar de Soap-instructies expliciet in staan. Voor de Arnold Schwarzeneggers onder ons is dit een heerlijke uitdaging. Het is waarschijnlijk dezelfde groep die het leuk vond om in zijn client/server-applicatie direct het TCP/IP protocol aan te roepen. Als u nuttigere dingen te doen hebt, dan raden we deze aanpak af.
Het belangrijkste is uiteraard het bouwen van de webservices zelf. Er bestaan hier globaal twee manieren voor. We kunnen bestaande software zodanig verpakken dat ze aanroepbaar wordt als webservice; dit wordt wel de ‘outside-in’ aanpak genoemd. Of we kunnen een nieuwe webservice definiëren en deze daarna invullen door bestaande software aan te roepen, de ‘inside-out’ aanpak. Beide hebben hun voor- en nadelen.
Leveranciers van applicatieservers zullen tools aanbieden voor de outside-in aanpak. Zij zullen hun producten zodanig uitbreiden dat de bestaande componenten met een minimale ingreep om te toveren zijn tot webservice. Bea Systems, Iona Technologies, Microsoft en Silverstream lopen hierbij voorop. Hoelang zullen we nog moeten wachten voordat we middleware-leveranciers als Merant en Openlink (beide groot geworden in het client/server tijdperk) dit gebied zien betreden? Nieuwe middleware-spelers hebben zich reeds gemeld, zoals Grand Central met hun Webservices Network.
Ook de leveranciers van EAI-tools (Enterprise Application Integration) zullen zich met deze markt gaan bemoeien. Tools van See Beyond, Tibco, Vitria en Webmethods zullen integratie via webservices ondersteunen.
De leveranciers van ontwikkelproducten zullen zich eerst richten op de ontwikkeling van gloednieuwe webservices. Bekende leveranciers als Borland met Delphi en Microsoft met Visual Studio.Net zijn reeds begonnen. En er zullen er ongetwijfeld nog vele volgen.
Ondanks dat de standaarden al enkele maanden bestaan, zijn de middleware en ontwikkelproducten nog erg nieuw. We bevinden ons met webservices in het prille begin. De discussie die zelfs nog moet losbarsten, is die over het ontwerpen van de interface van een webservice. Bij de outside-in aanpak zal de interface van een nieuwe webservice gelijk zijn aan die van een oude component. Maar is dat wel terecht? Moeten we bijvoorbeeld niet enkele componenten samenvoegen tot één webservice? Wat de perfecte interface is voor het aanroepen van een interne component over een lokaal netwerk, hoeft dat geheel niet te zijn als we die als webservice gepromoveerde component over het tragere en minder veilige internet aanroepen.
De eerste generatie webservices zal voornamelijk een opvraagfunctie hebben. Maar al snel zullen we transacties met webservices willen implementeren. Dit is nog een braakliggend terrein, want standaarden als Xaml (Transaction Authority Markup Language) en BTP (Business Transaction Protocol) zijn nog amper gereed.
Iedereen is enthousiast over webservices. Volgens de liefhebbers zal het de gehele economie op haar grondvesten doen trillen, maar enige gereserveerdheid is op zijn plaats. De eerste versies voor webservices zijn pas klaar, enkele ontwikkelproducten zijn zojuist beschikbaar gekomen en de middleware-producten moeten hun schaalbaarheid en snelheid nog bewijzen. Tevens moeten de ontwerpregels voor webservices nog bedacht worden. Het spel gaat eigenlijk nu pas beginnen!
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
