In deze magere tijden voor de it-industrie lijkt menig leverancier zich met de moed der wanhoop op een nieuw fenomeen te storten: webservices. Het gevolg is een niet aflatende stroom berichten over webservices waardoor velen door de bomen het bos niet meer zien. Om de verwarring nog groter te maken verleggen Sun en Oracle hun gebruikelijke stammenstrijd met Microsoft naar deze ontluikende technologie. En dat is jammer, want webservices kunnen voor een groot deel een einde maken aan de it-chaos binnen veel bedrijven en daardoor de kosten behoorlijk terug dringen.
Webservices zijn geen hype maar een verschijnsel dat iedere it-manager op zijn minst dient te bekijken en te overwegen. Ondanks veel opgeklopte lucht zijn webservices juist erg eenvoudig te maken en te gebruiken. En het mooiste is dat ze verschillende platformen en architecturen dichter bij elkaar brengen en leverancier- en platformonafhankelijk zijn. De reden voor de hype-vorming en de daaruit volgende voorzichtigheid is begrijpelijk: te veel aankondigingen over webservices hebben betrekking op e-handel en applicatieintegratie via internet. En van die koude kermis zijn we net teruggekomen. Het is waar dat webservices grote beloften voor toekomstige gegevensuitwisseling via internet inhouden, maar de echte schoonheid van webservices ligt in het feit dat deze nu direct toe te passen zijn en wel binnen de eigen organisatie.
Middleware
Volgens Charles Homs, analist bij Forrester Research, gaat zo’n 70 procent van het it-budget op aan het onderhouden van allerlei koppelingen en integratie van de veelheid aan verschillende applicaties die we binnen een doorsnee bedrijf aantreffen. Andere analisten komen tot soortgelijke conclusies. Er wordt dus heel wat afgeprogrammeerd aan eigengemaakte koppelingen tussen verschillende toepassingen. Niet alleen kost dit erg veel tijd en dus geld, maar degelijke koppelingen moet vaak worden aangepast omdat een van de applicaties wijzigt en de koppeling dan niet meer werkt. Daarnaast verspillen eindgebruikers ook erg veel tijd aan het handmatig uitwisselen van gegevens tussen verschillende applicaties. Op dit gebied komen webservices dan ook het best tot hun recht.
In zijn meest eenvoudige vorm is een webservice een soort middleware. Het vormt een doorgeefluik tussen twee applicaties. Op zich is dit niets nieuws, we kenden al Iiop (Corba), RMI (Java) en Dcom (Microsoft) als middel om gegevens tussen applicaties uit te wisselen. Het nadeel van deze methoden is dat er veel meer aan beide zijden moet worden afgestemd, waardoor het bijna onmogelijk is een universele service met een van deze methoden te bouwen. Een ander nadeel is dat deze methoden nogal platform- en leveranciergebonden zijn. Ook kunnen deze methoden onderling niet met elkaar omgaan. Webservices vormen in principe een vervanging van deze methoden en worden door praktisch iedere leverancier van betekenis ondersteund. Dat is het eerste grote voordeel: drie standaarden worden ingeruild voor één, waardoor de onderlinge uitwisseling enorm toeneemt.
Webservices hebben nog geen complete officiële standaard, ze zijn opgebouwd rond een aantal technologieën waarvan sommige wel en sommige niet zijn gestandaardiseerd. Niet iedere leverancier gebruikt dezelfde onderdelen, al is er nu wel een soort de facto standaard aan het ontstaan.
Ik weet niet wie de naam webservice heeft bedacht of waar deze het eerst werd gebruikt, maar de naam verwijst in ieder geval naar het transportprotocol http dat ook voor het Web wordt gebruikt. Webservices gebruiken dezelfde infrastructuur als de webbrowser. Dit betekent dat alle firewalls, routers en switches er mee kunnen omgaan. Er is geen enkele wijziging aan de infrastructuur nodig om webservices te kunnen gebruiken. Voor de beveiliging kunnen eveneens bestaande webtechnieken worden gehanteerd, zoals ssl en x.500 certificaten.
XML
Niet alleen het transportmechanisme gebruikt bestaande technieken, ook de verpakking van de informatie vindt plaats binnen bestaande afspraken. Het verzoek om gegevens en de gegevens zelf worden opgesteld in eXtensible Markup Language, xml dat evenals html van sgml (structured generalized markup language) is afgeleid. Een xml-document bestaat uit leesbare tekst waarin informatie-elementen tussen begin- en eindlabels, de zogenoemde tags staan. Een klant-‘record’ schrijven we als volgt:
Xml is niet de meest compacte manier om gegevens op te nemen, maar wel erg eenvoudig en leesbaar. Om gegevens in een xml-document te krijgen en ze aan de andere kant weer uit het document te halen, hebben we een xml-parser nodig. Met een dergelijk stuk gereedschap is het be- en verwerken van xml vrij eenvoudig. De gegevens binnen een xml-document zijn van alle platformafhankelijke franjes ontdaan en daardoor zeer eenvoudig over te dragen. Die overdracht van informatie verloopt via het Simple Object Access Protocol (soap). In de vorm van een soap-bericht versturen we zowel de feitelijke gegevens – het xml document – als de informatie wat te doen met de gegevens en hoe deze te behandelen. De instructies in het soap-bericht zijn eveneens volgens de xml-specificaties opgesteld.
Je zou een soap-bericht kunnen zien als een envelop met daarop de gegevens van de ontvanger en de afzender. In de envelop bevinden zich de gegevens, en instructies hoe met die gegevens om te gaan. Het opstellen van een soap-bericht is een nauwkeurig werkje, maar dit wordt bijna altijd door de vele gereedschappen voor webservices zelf afgehandeld.
Uddi-catalogus
Tot zover is er nog weinig nieuws onder de zon. De uit te wisselen gegevens worden in een moderne variant van de ‘comma separated file’ verpakt en met wat verdere informatie in een pakketje verstuurd. Echt nieuw aan de webservice zijn twee zaken die het gebruik en het ontwikkelen ervan veel eenvoudiger maken. We hebben het dan over een soort technische beschrijving van de service in de vorm van de Web Services Definition Language (wsdl) en een catalogus waarin allerlei webservices staan beschreven, de Universal Discovery Description Language (uddi). Beide specificaties zijn ook weer volgens de xml-taalregels opgesteld. De eerste is een technische beschrijving van de webservices waarin vastligt welke gegevens de service nodig heeft en welk resultaat terugverwacht mag worden. Deze beschrijving is zodanig opgesteld en gestandaardiseerd dat deze door een ontwikkeltool kan worden gelezen en begrepen. Het is dus mogelijk aanroepen voor een webservice te genereren met een webservice-toolkit. Dit scheelt de programmeur veel tijd en dat vermindert de kans op fouten. De toolkits stellen in het algemeen zelf het wsdl-document op aan de hand van de door een programmeur geschreven functie.
De uddi-catalogus is een soort gouden gids voor webservices. Hierin staan beschikbare services beschreven, inclusief de verwijzingen naar de wsdl-documenten. Een programmeur bladert door zo’n gids en zoekt de service uit die hij nodig heeft. Hij hoeft alleen maar zijn toolkit naar de juiste service te wijzen en het ontwikkelgereedschap genereert xml-documenten, soap-berichten en alles wat er verder nodig is om de service aan te roepen en het resultaat terug te krijgen. De ontwikkelaar kan zich volledig richten op het ophalen van de informatie die de service nodig heeft en het verwerken van het resultaat. De efficiëntie van ontwikkelaars neemt hiermee enorm toe; een programmeur hoeft geen uitgebreide kennis te hebben van de achterliggende systemen. Hij kan – mits er een webservice bestaat – zonder enige kennis van SAP vrij snel een programma maken dat een orderoverzicht uit het SAP-systeem tevoorschijn haalt.
Nachtmerrie
Webservices zijn vooral bedoeld om de functies en gegevens die binnen applicaties bestaan, voor de buitenwereld beschikbaar te maken en wel op een zodanige manier dat het vooral bedoeld is voor communicatie tussen programma’s. De daarbij gebruikte protocollen zijn eenvoudig en staan volledig los van platform of leverancier. De ontwikkelgereedschappen rondom webservices handelen veel zaken zelf af, waardoor de programmeur zich vooral op de inhoudelijke kant van de zaak kan concentreren en zich veel minder met allerlei technische zaken hoeft bezig te houden. Het mag duidelijk zijn dat wanneer alle applicaties over toegang via webservices zouden beschikken, de nachtmerrie van applicatieintegratie in korte tijd zou zijn opgelost. Daarom zijn alle grote leveranciers druk bezig hun programma’s van webservices te voorzien. Volgens analist Homs is het Duitse SAP hiermee het verst gevorderd en heeft het de duidelijkste visie van alle erp-leveranciers. SAP gaat alle functies binnen zijn productlijn voorzien van webservices en deze in een uddi-catalogus publiceren. Databases als DB2, Oracle en SQL Server bieden nu al xml-services om gegevens uit de database om te zetten naar xml en vice versa.
Een mooi voorbeeld van de voordelen die een webservice kan bieden betreft een autoverhuurbedrijf. Deze ontwikkelde in eerste instantie voor eigen gebruik een webservice front-end voor zijn verhuurapplicatie.
Een luchtvaartmaatschappij wilde naast tickets en hotels ook huurauto’s aanbieden. Het kostte maar weinig werk om de webservice van het autoverhuurbedrijf te integreren in hun eigen reserveringssysteem.
Het Haarlemse Timegrip heeft een applicatie voor een verzekeringsmaatschappij gemaakt. "De directie had behoefte aan geografische verkoopinformatie." zegt Marco van Gelder, directeur van Timegrip. "In plaats van een geografisch informatiesysteem aan te schaffen en hiervoor zelf de programmatuur te maken, gebruiken we nu een webservice die dit voor ons doet. Het kostte maar een paar dagen programmeren om die webservice vanuit onze software aan te roepen. We sturen de informatie via het Web naar de aanbieder en krijgen keurige kaarten terug. Zonder webservices waren we veel meer tijd kwijt geweest nog afgezien van het feit dat we geen gis-systeem hoefden aan te schaffen en te onderhouden."
Platformonafhankelijk
Zoals gezegd zijn webservices – zowel bij het maken als het gebruiken – platform- en leverancieronafhankelijk. Een SAP-systeem draaiend op Unix kan zonder problemen gegevens uitwisselen met een voorraadsysteem dat op Windows NT draait. In principe kan iedere programmeertaal of platform worden gebruikt om webservices te maken of aan te roepen. De twee dominante omgevingen zijn Java en Microsoft .Net. Het verschil tussen beide omgevingen wordt echter steeds kleiner. Bij de keuze voor een bepaalde omgeving kan met zich het best laten leiden door bestaande relaties, al opgebouwde kennis van een omgeving en bestaande systemen en platformen. In een Unix-omgeving is Java waarschijnlijk de beste keuze. Weblogic, IBM en Borland leveren uitgebreide gereedschappen voor het maken en gebruiken van webservices. Ook in de ‘open source’-gemeenschap bestaat een groot aantal producten, al zijn deze wat minder elegant dan hun commerciële tegenhangers. Vooral Resin is het overwegen waard. Wie vooral met Windows en Intel werkt, kan niet om Microsoft heen. Het nieuwe Visual Studio .Net is naar mijn mening een van de mooiste en bruikbaarste ontwikkelomgevingen voor webservices. De hele .Net-omgeving is gebouwd rondom xml en webservices vormen daarvan een natuurlijk onderdeel. De nieuwe taal C# lijkt zoveel op Java dat programmeurs hier snel mee overweg kunnen. Overigens is het ook mogelijk webservices te bouwen met Delphi van Borland. Gartner verwacht dat in de toekomst zo’n 40 procent van de applicaties in .Net worden gemaakt, 40 procent in Java en 20 procent op bedrijfseigen platformen.
Oplossing voor applicatie-integratie
Webservices bieden een mogelijke oplossing voor de kostenverslindende problematiek van interne applicatie-integratie. Naarmate er meer webservices ontstaan, wordt het eenvoudiger ze te integreren met applicaties van derden. Daarnaast zijn eenmaal ontwikkelde webservices voor meerdere – nu wellicht nog onbekende – doelen te gebruiken en is er veel minder kennis van allerlei applicaties nodig bij programmeurs die webservices willen gebruiken. Ook vergen webservices nauwelijks nieuwe investeringen in infrastructuur of specifieke kennis. Ontwikkelgereedschappen zijn breed beschikbaar, ook in ‘open source’-varianten, en nemen de programmeur veel van de technische details uit handen. Bij de aanschaf van nieuwe applicaties is het verstandig de beschikbaarheid van webservice-toegankelijkheid fors te laten meewegen. Natuurlijk zijn er hier en daar nog wat haken en ogen en losse eindjes, maar die vormen zeker geen reden tot een afwachtende houding. De sterk in opkomst zijnde portalen maken de behoefte aan webservices alleen nog maar groter en lossen tevens een aantal van de workflow- en integratieproblemen op.
Begin eens met een webservice te bouwen voor toegang tot personeelsgegevens. Herschrijf het webtelefoonboekje om deze webservice aan te roepen en u zult merken dat op veel meer plaatsen behoefte bestaat aan toegang tot personeelsinformatie.
Meer informatie is te vinden op http://www.webservices.org
Eric Roijen, freelance medewerker
