Web Services, alleen marketing, of toch niet…

Van een afstand kijkend naar de ICT markt levert als resultaat een tweetal speerpunten waar alles om draait. De ene is organisatie of beter reorganisatie gericht, de ander is puur technisch, innovatief gericht. Het gaat hierbij om webservices. Een flink gehypte term die te pas en te onpas wordt gebruikt. Het lijkt erop dat webservices dé oplossing vormt van alle problemen die bedrijven tegenkomen in hun jacht naar reductie van kosten, verbreding van de afzetkanalen of versnelling van het naar de markt brengen van nieuwe producten. Als het leven toch eens zo simpel was. Het doel van dit artikel is inzicht te verschaffen in een stuk techniek achter webservices. Dit inzicht is puur bedoeld om de mogelijkheden en onmogelijkheden van het toepassen van webservices te kunnen plaatsen. Het is zeker niet bedoeld om een gedetailleerd programmeurtraining te bieden.


Wat zijn Webservices


Een eerste stap is het bepalen van wat webservices nu precies zijn. Een eenvoudige definitie is min of meer een letterlijke vertaling, ofwel het aanbieden van een dienst via het web. Deze definitie dekt echter niet de volledige lading. Als in plaats van web gekozen wordt een standaard internet netwerk wordt de definitie al breder en juister. Een simpele vergelijking van één webservice met iets uit de dagelijkse praktijk kan worden gebaseerd op het elektriciteitsnetwerk. Vergelijk een webservice met een stopcontact dat op een standaard manier (via een stekker) via een gestandaardiseerd netwerk een dienst (elektriciteit) levert. Om van een dergelijke dienst gebruik te maken heb je dus alleen maar een stekker nodig. Je hoeft geen eigen elektriciteitscentrale te bezitten en je hebt geen kennis van de werking van een elektriciteitscentrale nodig. Kort door de bocht, maar gezien vanuit een gebruiker is dit precies wat een webservice moet doen. Namelijk een standaard interface bieden voor een dienst die door een gespecialiseerde organisatie wordt aangeboden. Hierdoor wordt invulling gegeven aan het ‘schoenmaker blijf bij je leest’ principe en kan door het integreren van deze standaarddiensten eenvoudig een applicatie of proces opgezet worden. Helaas is dit spreekwoord in de praktijk zelden van toepassing. Veel organisaties hebben of zijn bezig een elektriciteitscentrale in huis te halen.
Met deze vergelijking wordt onbewust ook één van de huidige zwaktes van webservices aangeraakt. De bekabeling is al jaren gestandaardiseerd. Het probleem zit hem echter in de aansluitpunten, de stekker en het stopcontact. Elk land heeft zijn eigen ‘standaard’. Hetzelfde geldt voor webservices. De bekabeling, dus het netwerk, is gestandaardiseerd. De koppelstukken tussen applicaties en de gebruikers van diensten zijn echter niet gestandaardiseerd. Dit zorgt ervoor dat de traditionele uitdagingen om de hoek komen kijken die al jaren spelen rond applicatie ontsluiting in bijvoorbeeld standaardcomponenten. De ervaring leert dat ‘Plug-and-Play’ hier niet met stip genoteerd is en dat de complexiteit niet zit in het leggen van de kabel en het aanbieden van een min of meer gestandaardiseerd stopcontact. Nee, de complexiteit zit voornamelijk in het aansluiten van de bestaande applicatie. Systemen die draaien onder MVS, OS/390, UNIX of Windows met applicaties geschreven in Cobol, VisualBasic, Java, PL/1 of andere programmeertalen. Applicaties die nooit gemaakt zijn om ontsloten te worden en waar dus werk aan de winkel is om een aansluiting met de buitenwereld te realiseren. Dat niet elke applicatie eenvoudig ontsloten kan worden neemt niet weg dat mits ontsloten via webservices, dus het aanbieden van een standaardkoppeling, wel degelijk voordelen heeft. Gelukkig komen er met de dag meer hulpmiddelen om het leven van de applicatie ontsluiter te verlichten.



De fundamenten van webservices


Webservices maken gebruik van een combinatie van XML en Internet standaarden. De belangrijkste onderdelen binnen Webservices zijn:

  • Simple Object Access Protocol (SOAP), de basistechniek om functionaliteit aanroepbaar te maken.
  • Web Service Definition Language (WSDL), de definitie taal om de aangeboden diensten te beschrijven
  • Universal Description, Discovery and Integration (UDDI), het mechanisme om diensten op een centrale locatie vast te leggen en vindbaar te maken voor gebruikers.



SOAP


SOAP is ontwikkeld om het uitwisselen van informatie in gedistribueerde omgevingen te standaardiseren en te vereenvoudigen. Het is een protocol dat XML gebruikt om het berichtformaat te beschrijven. Daarnaast maakt het gebruik van HTTP, het standaard Internet communicatie protocol, om de berichten tussen systemen te versturen.
SOAP is een RPC-achtig (Remote Procedure Call) mechanisme. Er wordt een vraag gesteld en er volgt direct een antwoord, waarna de verbinding verbroken wordt. Het doel van SOAP is het op een standaard manier bieden van toegang tot een functie. Het kan gezien worden als een schil die rond een ontwikkelde functie wordt aangebracht. De implementatie van de functie, ofwel de code, zorgt dat de aangeroepen service doet wat hij moet doen. Zo’n functie kan zowel een nieuw of bestaand component zijn of een bestaande legacy functie. De informatie die nodig is om de functie aan te roepen en het resultaat dat terugkomt van de functie wordt in een XML structuur geplaatst, het zogenaamde SOAP-bericht. De SOAP schil is generiek en kan gebruikt worden om alle types componenten aan te sluiten. Het is niet langer zo, dat een CORBA object op z’n CORBA’s aangeroepen moet worden en een COM component op z’n COM’s. Nee, alle functionaliteit kan op één uniforme wijze, met SOAP, aangeroepen worden, wat duidelijk een voordeel biedt.
Het gaat te ver om SOAP uitgebreid te behandelen, maar de opbouw is vergelijkbaar met het normale briefverkeer. Er is een envelop, waarop het adres van de organisatie staat. In de envelop zit de brief die gericht is aan een afdeling en daarnaast de feitelijke gegevens bevat. Vertaald naar een webservice geeft de envelop aan waar de dienst draait, vervolgens wordt de dienst gespecificeerd en wordt de data die nodig is om de dienst te kunnen uitvoeren meegeleverd. In het voorbeeld wordt de dienst getPrice geraadpleegd die een tweetal gegevens, product en aantal, verwacht om de prijs te bepalen.

POST /getPrice HTTP/1.1
Host: http://www.softwareag.nl
Content-Type: text/xml; charset="utf-8"
Content-Length: 418

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<app:getPrice xmlns:app="http://www.softwareag.nl/prices">
<product>Tamino</product>
<amount>10</amount>
</app:getPrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

voorbeeld 1 - Een SOAP verzoek



WSDL


De dienst is ontsloten en toegankelijk gemaakt via SOAP. Het is nu zaak om de dienst zodanig te beschrijven dat deze ook daadwerkelijk gebruikt kan gaan worden. Hiervoor is de ‘Web Service Definition Language’ ontwikkeld. Een op XML gebaseerde taal die beschrijft hoe de functie aangeroepen moet worden, welke gegevens door de dienst verwacht worden, wat het transportmedium is en hoe het antwoord gestructureerd is. De webservice beschrijvingen worden vervolgens kenbaar en toegankelijk gemaakt via UDDI. Dit moet direct vraagtekens oproepen. Immers, hoe wordt omgegaan met de semantiek van dergelijke definities. Is het mogelijk om op een uniforme, eenduidige en begrijpbare manier diensten te beschrijven. Dit is een probleemgebied waarvoor in de versie 1.0 van webservices geen oplossing voorzien is. Zo kan ik prima koffie via een webservice aanbieden. Dan zal de gemiddelde lezer direct denken aan een lekker bakkie troost, maar de aanbieder blijkt een havenoverslagbedrijf te zijn dat zich richt op branderijen. In de komende versie(s) van webservices wordt druk gewerkt om via taxonomieën afspraken rond berichtdefinities en interpretaties te standaardiseren.



UDDI


De aangeboden diensten kunnen kenbaar gemaakt worden via mechanisme waarbij elke organisatie zorgt voor het beheer van de eigen gegevens. Hierdoor wordt het extreem moeilijk om vrij aangeboden diensten te vinden. Het is echter een mogelijk scenario indien de partijen die gebruik mogen maken van de diensten op voorhand bekend zijn. Een betere oplossing is het vastleggen van de informatie omtrent de aangeboden diensten op een centraal toegankelijke locatie. Zeker indien hiervoor een uniform mechanisme wordt gekozen kan door het stellen van een eenvoudige, gestandaardiseerde vraag aan dit centrale orgaan onderzocht worden welke diensten er aangeboden worden. Figuur 1 geeft een inzicht in de complexiteitsverschillen tussen het ‘beheren van de eigen informatie’ en het gebruiken van een zogenaamde ‘centrale repository’ voor het beheren van de gegevens.
UDDI is zo’n centrale op XML gebaseerde repository. De volledige naam zegt het al, UDDI is bedoeld om gegevens te beschrijven en te ontdekken. Het vormt het hart van een webservices systeem. Enerzijds worden de aangeboden diensten vastgelegd op een centrale locatie, anderzijds is het mogelijk om op een uniforme manier vragen af te vuren om gewenste diensten te zoeken. UDDI wordt vaak vergeleken met de telefoongids. Net als in een telefoongids is in een UDDI repository informatie opgeslagen in een bepaalde gelaagdheid. De eerste laag zijn de basisgegevens over bedrijven, vergelijkbaar met het ‘ouderwetse’ deel van de telefoongids. De tweede laag levert informatie over de diensten die aangeboden worden door de bedrijven, vergelijkbaar met het roze gedeelte, de bedrijvengids. In de laatste laag worden de voorkeursmethoden voor het verrichten van transacties kenbaar gemaakt. De gegevens worden in de UDDI repository opgeslagen in het WSDL formaat.
Interessant, en direct bruikbaar binnen een organisatie. Alle ingrediënten zijn relatief eenvoudig op te zetten en het kenbaar maken van de locatie van de UDDI repository is kinderspel. Zeker in vergelijking met een bredere opzet waarbij gedacht wordt aan het aanbieden van webservices via het Internet. Hier spelen heel andere zaken een rol. Hoe vind ik een UDDI repository waar ik mijn diensten aan kan bieden? Hoe vind ik diensten, is er een zoekmachine die de beschikbare repositories ondervraagt of zelfs kent? Hoe beschrijf ik behalve technisch en praktisch mijn diensten ook op een aantrekkelijke manier om gebruik aan te moedigen? Zo zijn er nog een set van vragen te stellen die in de nabije toekomst beantwoord gaan worden. De eerste stap kan echter reeds gezet worden door de voordelen die webservices bieden intern of gesloten omgevingen (met bekende partners) toe te passen. Tegen de tijd dat de juiste of voldoende repositories (zie het als dienstenmakelaars) ontstaan bestaat de inspanning louter uit het aanmelden van deze diensten.



Het gebruiken van een webservice


Om gebruik te kunnen maken van een webservice zijn een aantal stappen noodzakelijk.
Stap 1 - De elektronische dienst (functie) wordt via SOAP (Simple Object Access Protocol) als webservice beschikbaar gemaakt.
Stap 2 - Registreren van de aangeboden dienst op een centrale plek. Deze repository, gebaseerd op UDDI (Universal Description, Discovery and Integration) legt gegevens vast over de organisatie die de dienst aanbiedt, informatie over de dienst zelf en een gebruiksbeschrijving van de dienst.
Stap 3 - Een ‘gebruiker’ gaat op zoek binnen de repository naar diensten die een antwoord kunnen bieden op een vraag
Stap 4 - Na het vinden van een dienst in de repository wordt de verbinding gemaakt met de aanbiedende organisatie en wordt de dienst aangeroepen.



Waar bieden webservices toegevoegde waarde


De gebieden zijn eerder kort aangestipt. Standaardisering van de diensten gaat door het toepassen van webservices op een tweetal niveaus. Enerzijds het technisch beschikbaar maken en aanroepen van individuele diensten. Anderzijds de mogelijkheid om berichtdefinities, dus de resultaten van een aangeroepen dienst, te standaardiseren. Hierdoor wordt het technisch mogelijk en zelfs relatief eenvoudig om één geconsolideerd klantensysteem binnen een organisatie aan te bieden. Met de nadruk op technisch, want de grootst remmende factor is alles behalve de techniek. Binnen de eigen organisatie kan echter stevig bespaard worden door het oplossen van dergelijke niet-technische barrières en is zeker gezien de huidige economische situatie voldoende kracht aanwezig om deze hobbels te slechten. Zodra buiten de organisatie getreden wordt is het sturend of aanpassend vermogen direct beperkter en wordt het toepassen van webservices hierdoor minder aantrekkelijk.
Naast problemen die meer politiek van aard zijn geldt voor het toepassen van webservices buiten de bedrijfsgrenzen ook het vraagstuk beveiliging. Hoe bepaal ik de authenticiteit van de gebruiker of de dienst. Is het mogelijk de berichten versleuteld te versturen. Allemaal vraagstukken waar de afgelopen periode stevig aan de weg getimmerd is en oplossingen op de markt gekomen zijn. Het is pas sinds september 2002 dat er een working draft bestaat hoe webservices beveiligd kunnen worden, er is echter nog geen geaccepteerde standaard.
Het is logisch te verwachten dat webservices verder uitgekristalliseerd moeten zijn voordat het daadwerkelijk toegepast kan gaan worden buiten de bedrijfsmuren. Dit is ook het moment dat vraagstukken rond verrekening van diensten aan de orde komen, waarbij de meest wilde verrekeningsmodellen tot de mogelijkheden zullen behoren. Variërend van per stuk tot abonnementen voor ongelimiteerd verbruik.



Conclusie


Webservices is een boeiende technologie die volop in de belangstelling staat en volop in beweging is. Ondanks het feit dat het nog een relatief jonge techniek is, biedt het al duidelijke mogelijkheden om binnen organisaties toe te passen. Door standaardisering van diensten kan eenvoudiger integratie en hergebruik gerealiseerd worden, wat leidt tot de op dit moment o zo noodzakelijke kostenbesparingen. Kijkend naar de ontwikkelingen wordt voornamelijk gewerkt om de huidige beperkingen, als standaardisatie van dienstbeschrijving en dienstomschrijving, maar ook beveiliging op te lossen.
De vraag die zich opwerpt is, hoe op een veilige en kosteffectieve manier een eerste stap gezet kan worden in de wereld die webservices heet. Ofwel de papieren voordelen terug te laten komen als financiële voordelen. Het advies hierbij is om een project van beperkte omvang op te zetten. De juiste kennis en ervaring inbrengen van de ‘dun gezaaide’ experts van het eerste uur en zo een vliegende start naar een succesvolle implementatie te maken. Het is in feite niet een vraag van of, maar meer van wanneer te beginnen…