Het vorige artikel sloot af met de stelling dat webservices een implementatie van SOA is. Het is een manier - een van de vele - om een SOA te realiseren. Maar het is niet alleen een zeer goede implementatie van SOA, het is ook de enige kandidaat om de standaardtoepassing van SOA te worden.
Dit artikel is volledig gewijd aan webservices: vanaf de eerste beginselen tot en met de webservicesarchitectuur die zorgt voor robuuste, bedrijfskritische toepassingen. Daarnaast komt het proces van webservicesspecificatie en standaardisatie aan de orde en ik sluit af met de prominente rol die Microsoft speelt in de ontwikkeling van webservices. Microsoft wordt door velen, waaronder Gartner, gezien als de trekker van het we services initiatief.
Pre-webservices
Voordat er sprake was van webservices waren er andere manieren om een SOA- applicatielandschap te verwezenlijken. In de jaren negentig ontstond er een sterke belangstelling voor applicatie-integratie (EAI = Enterprise Application Integration): het op elkaar laten aansluiten van bestaande applicaties die niet op elkaar waren afgestemd, maar waar wel de behoeft aan informatieuitwisseling en afstemming was.
Dus kwam veelal de eigen ICT-afdeling met oplossingen om informatie uit applicatie A te halen en die aan applicatie B aan te bieden en vice versa. Die oplossingen bouwde men ofwel helemaal zelf of men gebruikte technologie van leveranciers die als Message Oriented Middleware (MOM) te boek stond. Denk daarbij aan IBM's MQseries, Tibco's Rendezvous of Microsoft's MSMQ technologie. Later kwam daar de message brokering-technologie bij, waarbij de gegevensuitwisseling tussen applicaties beter (lees centraler: in een hub-and-spoke model) werd gestructureerd.
Voor al die oplossingen gold dat het uitwisselen van informatie of het aanroepen van functies in andere applicaties op een gesloten, bedrijfseigen (‘proprietary') manier plaatsvond. Daardoor kreeg men binnen de onderneming een ‘lock in'. Hiermee was de uitwisseling van informatie met andere ondernemingen en hun applicaties niet opgelost want elke onderneming gebruikte zijn eigen integratietechnologie.
In 1999 werd SOAP gelanceerd. SOAP staat voor Simple Object Access Protocol. Het is gebaseerd op XML, een protocol dat volledig leveranciers-, machine-, en taalonafhankelijk is en zelfs door mensen te lezen en te bevatten is.
SOAP was gelanceerd om de toepassing en het succes van het World Wide Web (WWW) uit te breiden van mensgerichte communicatie naar machinegerichte communicatie. Het WWW was een ware revolutie waarin mensen heel gemakkelijk en volledig vrij konden ‘surfen' naar welke omgeving dan ook en daar informatie konden ophalen en transacties uitvoeren. SOAP wil datzelfde bereiken in de communicatie tussen machines of - beter nog - tussen de programma's op die machines. SOAP markeerde het begin van het webservicestijdperk en SOAP staat daarin nog altijd centraal.
Webservices: het principe
Advies van de auteur: deze paragraaf is bestemd voor hen die nog weinig van webservices afweten. De lezer die het supertrio van SOAP, WSDL en UDDI (zie figuur 1) al in de vingers heeft kan beter direct de volgende paragraaf induiken.
SOAP is een protocol waarmee men objecten of liever services kan benaderen. Tussen de services worden SOAP-berichten uitgewisseld. Een SOAP-request bevat een verzoek aan een object (dus: service) en een SOAP-response geeft het antwoord op dat verzoek.
Het fraaie van SOAP is dat het niets weet of wil weten van hoe die service is geïmplementeerd. SOAP betreft alleen een in neutrale, voor iedereen duidelijke termen gestelde vraag of gegeven antwoord. Of de service aan wie het verzoek gesteld wordt intern geïmplementeerd is in Cobol, C, Visual Basic, Java of Assembler; of het draait onder Unix/Linux, MVS/zOS of Windows en zich fysiek bevindt op een pc, mainframe, pda of smartphone geleverd door IBM, Dell, HP of Nokia, is totaal irrelevant.
Het enige wat telt is dat de vragende service in staat is het verzoek samen te stellen, te adresseren en op te sturen en de bevraagde service het verzoek kan begrijpen, uitvoeren en - indien nodig - een antwoord kan samenstellen en terugsturen naar de vragende service.
Als de service een ‘native' webservice is, dan zal de service in staat zijn om direct SOAP-berichten te consumeren en produceren. Als de service een applicatie of module is dat intern geen weet heeft van SOAP dan kan de applicatie/module verpakt (‘wrapped') worden in een laag die het inkomende SOAP-bericht oppakt en vertaalt naar de taal die de applicatie/module wel begrijpt en omgekeerd het antwoord vertaalt naar SOAP en vervolgens stuurt naar de aanvrager van het verzoek. Daarmee is het protocol dat tussen services besproken wordt volledig onafhankelijk van het protocol dat binnen de service gehanteerd wordt.
De service die de SOAP-berichten behandelt moet op de een of andere manier aangeven wat hij wel en niet kan behandelen en hoe hij het verzoek opgesteld wil zien: de naam van het verzoek en de gegevens van het verzoek. Voorbeeld: aan een klantinformatieservice kan het verzoek ‘geef_klantinformatie' gesteld worden waarbij een 10-cijferige klantcode moet worden meegegeven. De aanvrager moet het verzoek precies volgens de eisen van de serviceleverancier opstellen, want anders kan de serviceleverancier het niet in behandeling nemen.
Een service biedt vaak meerdere van dit soort verzoeken. Sommige van die verzoeken zijn enkelvoudig - dat wil zeggen een enkel verzoek met een enkel antwoord - maar andere verzoeken hebben meer de vorm van een conversatie, een vraag en antwoordspel waarbij eerst verzoek 1 in behandeling wordt genomen en daarna verzoek 2 etc.
De Web Services Description Language (WSDL) is het document waarin de serviceleverancier aangeeft welke verzoeken hij in behandeling neemt (en de volgorde daarvan), welke gegevens daarbij moeten worden aangeleverd, welke antwoorden hij geeft (met welke gegevens) en niet te vergeten: wat zijn adres is.
Het adres van de service moet uniek zijn en heeft vaak de vorm van een URL (Uniform Resource Locator), een standaard om het adres van een ‘resource' aan te geven; een webservice is een ‘resource'. WSDL is net als SOAP gebaseerd op XML.
Het is de verantwoordelijkheid van de serviceleverancier/producent om met behulp van WSDL aan te geven welke services hij te bieden heeft. De SOAP afnemer/consument leest de WSDL, produceert op basis daarvan zijn verzoek(en) en stuurt die naar het aangegeven adres. De volgende vraag die je je daarbij kunt stellen is: hoe weet de afnemer/consument welke webservices er zijn?
Een methode die daarbij gebruikt kan worden is het aanleggen van een centrale directory van webservices, een soort telefoonboek waarin men alle services kan vinden op naam, maar ook op soort geboden service (vergelijk de gouden gids), op organisatie die de service aanbiedt, etcetera. Die centrale directory noemt men UDDI (Universal Description, Discovery and Integration).
Daarmee kom ik op figuur 1, waarin de basisprincipes van webservices staan: een webserviceproducent biedt een webservice aan dat een aantal verzoeken in zich bergt. De webservice kan ‘native' als webservice ontwikkeld zijn of het kan een ‘wrapper' zijn om een bestaande applicatie/module. In elk geval staat in het WSDL document beschreven wat de webservice aan functionaliteit te bieden heeft.
De webservice kan zichzelf aan de wereld bekend maken door opgenomen te worden in een directory met webservices, de UDDI repository. Daarbij kan de UDDI een private directory zijn die alleen binnen de onderneming bekend is, een publieke directory die voor iedereen toegankelijk is of een vorm daartussen waarbij de directory alleen toegankelijk is voor een beperkt aantal organisaties - zoals de partners, toeleveranciers en afnemers van de onderneming die de webservice(s) publiceert.
Figuur 1: Basisprincipes van webservices
Webservices: uitbreiding
De in de vorige paragraaf besproken basis maakt het mogelijk dat webservices gedefinieerd, geregistreerd en gebruikt worden. De periode 2000 - 2002 is vooral gebruikt om die basis neer te zetten en webservices bekendheid te geven. En dat is aardig gelukt. Webservices heeft zich in betrekkelijk korte tijd van hype ontwikkeld tot bekend en geaccepteerd fenomeen. Niet langer is de vraag of webservices algemeen toegepast gaat worden, maar wanneer.
Een grote rol bij de snelle marktacceptatie van het fenomeen webservices lag in de relatieve eenvoud van het model. Maar daar zat ook een probleem. De werkelijkheid van gedistribueerde softwaretechnologie is veel complexer. Met SOAP, WSDL en UDDI kan men weliswaar webservices implementeren, maar er wordt niets gezegd over de veiligheid en betrouwbaarheid van die webservices, de mogelijkheid web services te combineren en orkestreren tot bedrijfsprocessen waarbinnen men transacties kan uitvoeren of het management van al die webservices.
Vanaf 2001 is achter de schermen hard gewerkt aan het verbeteren van de webservicesspecificaties en -architectuur. Er volgde een ontwikkeling van eenvoudige ‘zo kan het' model van figuur 1 naar de veel complexere ‘zou moet het' webservicesarchitectuur van figuur 2.
Daarbij zijn alle registers van ‘distributed computing' opengetrokken. Alle kennis die de afgelopen 30 jaar is opgedaan op het vlak van veilig en betrouwbaar gedistribueerd werken zijn en worden in de webservicesarchitectuur opgenomen.
Tientallen webservicesspecificaties hebben de afgelopen drie jaar het licht gezien. De specificaties zijn vrijwel altijd door een (soms wisselend) consortium van bedrijven gepubliceerd. Sommigen van die specificaties zijn aanvullend op elkaar, andere overlappend en weer andere zijn concurrerend. Het lijkt een onbegrijpelijke kakofonie te worden en degenen die zo gecharmeerd waren van de eenvoud van webservices vragen zich verbijsterd af waar het naartoe moet gaan.
Maar er zijn zeker zes redenen waarom het webservicesfenomeen eerder sterker dan zwakker is geworden met de uitbreiding van al die specificaties.
Op de eerste plaats was het nodig dat web services robuuster werden; de werkelijkheid van ‘distributed computing' is nu eenmaal complex en voor niets gaat de zon op. Het beveiligen van het berichtenverkeer is een noodzakelijke voorwaarde voor acceptatie van webservices bij bedrijfskritische toepassingen, bij financiële transacties om maar eens wat te noemen.
Het implementeren van SOA in de ICT is de meest ingrijpende operatie die men zich voor kan stellen. Maar het wordt - net als SOA in de business - gedreven door economische principes en er is derhalve geen ontkomen aan. Het is gewoon de volgende stap in de ICT evolutie.
Op de tweede plaats: het webservicesinitiatief is en blijft iets dat door vrijwel de gehele ICT-wereld wordt gedragen. Het is voor het eerst dat er zo'n grote ondersteuning is door en samenwerking tussen leveranciers op het vlak van gedistribueerde softwaretechnologie. Dat momentum moet worden vastgehouden omdat het uiteindelijk in het belang is van alle gebruikers van gedistribueerde ICT; en in een SOA-wereld is iedereen daarvan een gebruiker.
Op de derde plaats is er bij al die uitbreidingen in principe niets nieuws verzonnen. Principes om berichten te beveiligen, het verwerken van berichten te verzekeren, transacties uit te voeren en afzonderlijke taken tot samengestelde en gecoördineerde processen samen te voegen, zijn al uit allerlei gedistribueerde technologieën bekend zoals TP-monitoren, Message Oriented Middleware en Workflow engines. Er is met die specificaties niets nieuws onder de zon. Voor het eerst zijn ze nu op een implementatie onafhankelijke manier gedefinieerd en met veel samenwerking tussen bedrijven die elkaar normaal gesproken alleen maar beconcurreren.
Op de vierde plaats kunnen de specificaties best complex zijn zonder dat de gebruiker van de webservicetechnologie daar last van hoeft te hebben. De meeste specificaties verdwijnen bij het implementeren van die specificaties onder de motorkap. Het is de taak van de softwareleveranciers die de specificaties omzetten tot technologische producten om dit zo te doen dat de architect en ontwikkelaar geen last hebben van die complexiteit.
Welke architect bemoeit zich bij een gedistribueerde database-transactie met de ins en outs van het Two-Phase Commit (2PC) protocol? Welke ontwikkelaar houdt zich bezig met de encryptie en decryptie van berichten over een beveiligde internetvebinding? Dit alles is verstopt in de technologie. Resumerend: complexe specificaties betekenen niet dat de technologie zoals die zich aan de architect/ontwikkelaar - en laat staan aan de gebruiker - voordoet ook complex moet zijn. Bij voorkeur niet zelfs.
Ten vijfde betekent de concurrentie die men soms tussen de verschillende webservicespecificaties ziet dat de marktwerking ervoor zal zorgen dat de beste en sterkste specificaties zullen overblijven en het tot echte standaard maken. Er is een proces gedefinieerd dat een webservicespecificatie doorloopt: van voorgestelde specificatie tot en met gecertificeerde implementatie.
Tenslotte is er een prachtig mechanisme in de webservicesarchitectuur ingebouwd waardoor bij het gebruik van webservices alleen die componenten gebruikt hoeven te worden die ook echt nodig zijn. Ook is het mogelijk later bepaalde componenten toe te voegen, te wijzigen of te verwijderen. We hebben het hier over de ingebakken uitbreidbaarheid en ‘composability' van de web services architectuur.
Op het eerste en de beide laatste argumenten gaan de volgende twee paragrafen dieper in.
Webservices: van specificatie tot standaard
De webservicesspecificaties worden volgens een gestructureerd proces ontwikkeld en verbeterd. Ik kan dat proces het allerbest vanuit het perspectief van Microsoft beschrijven. Allereerst wordt op een bepaald vlak van distributed computing een of meerdere partners gezocht om de betreffende specificatie te gaan realiseren. Daarbij speelt een mengelmoes van kennis/kunde, politiek en de marktslagkracht een rol.
In het begin is heel veel de samenwerking met IBM gezocht. Enerzijds hebben Microsoft en IBM veel kennis van alle facetten van distributed computing en beiden hadden vanaf het prilste begin ingezien dat webservices een must waren om het nijpende probleem van de heterogeniteit van systemen en applicaties op te lossen.
Het volgen van de ‘zuivere', volledig democratische route van de standaardisatieorganisatie zou het ontwikkelproces met vele, vele jaren vertragen zo heeft de geschiedenis uitgewezen. Het gebruik maken van de marktslagkracht van de beide reuzen op softwaregebied zou het proces versnellen en dat is ook gebeurd. Maar daarnaast werden per specificatie specifieke partners aangezocht mee te werken die echt subject matter kennis hadden in te brengen zoals Verisign en RSA op het gebied van beveiliging en BEA en Tibco op het gebied van reliable messaging.
Nadat de initiële specificatie is gepubliceerd, worden er feedback-workshops gehouden die open staan voor ieder die commentaar wil leveren. Daarna volgt een ‘proof of concept' waarin twee of meer deelnemers bewijzen dat de specificatie in technologie geïmplementeerd kan worden en dat de implementaties van verschillende leveranciers ook echt met elkaar werken.
Beide workshops leiden vaak tot aanpassing en verfijning van de specificaties. Als er voldoende vertrouwen is in de stabiliteit van de specificatie, wordt deze aan een van de standaardisatie organisaties aangeboden. In de meeste gevallen wordt een keuze gemaakt tussen W3C en OASIS. Die moeten de specificaties verder uitwerken en als officiële standaard poneren.
Het proces van specificatie is daarmee voor die versie van de betreffende specificatie afgelopen. Nu moeten de leveranciers de specificatie inbakken in hun technologie. Maar bij de vertaalslag van specificatie naar technologie kunnen interpretatieverschillen er toe leiden dat de producten van de verschillende leveranciers niet goed met elkaar samenwerken. En dat zou de essentie van webservices teniet doen: leveranciersonafhankelijke gedistribueerde software technologie.
Daarom is in 2002 door Microsoft, IBM, BEA en Intel de WS-I opgericht: de Web Services Interoperability Organisation. Deze organisatie, waar inmiddels ongeveer 200 bedrijven aan deelnemen, maakt profielen op basis van de specificaties waarmee leveranciers - of anderen - kunnen testen of hun implementatie van webservices overeenkomt met de bedoeling van de specificaties.
De hele idee van samenwerking tussen concurrenten op het vlak van webservices is natuurlijk niet uit liefdadigheidsoverwegingen opgezet. Aan de ene kant eist de markt dat applicaties beter met elkaar samen kunnen werken en is er druk op de leveranciers de interoperabiliteit tussen de diverse technologieën te verbeteren: vandaar die samenwerking. Aan de andere kant is en blijft er een enorme competitie: wie is er in staat de beste, meest succesvolleweb services technologieën te realiseren.
En op dat laatste vlak is de strijd nog maar net begonnen!
Webservicesarchitectuur
Figuur 2 geeft de webservicesarchitectuur weer. Het voert te ver om in dit artikel alle afzonderlijke specificaties te beschrijven. Aan het eind van het artikel is een aantal links opgenomen voor degenen die een goed overzicht van de webservicesarchitectuur willen hebben. Ik ga hier slechts in op een drietal punten.
Ten eerste is de webservicesarchitectuur losgekoppeld van het transportmechanisme. In de eerste versies van webservices was SOAP nog sterk gekoppeld aan het http transportprotocol waarvan ook het www (http en html) gebruik maakt. Nu is die koppeling losgelaten en wordt bijvoorbeeld het adres van de webservicelocatie in SOAP zelf opgenomen (waar eerst nog gebruik werd gemaakt van http adressering). Dat betekent dat SOAP-berichten nu over elk protocol gestuurd kunnen worden en onderweg zelfs van transportmechanisme kunnen wijzigen. Dat kan bijvoorbeeld handig zijn voor SOAP-berichten die vanaf mobiele devices naar data centers gestuurd worden en over meerdere transportprotocollen heengaan.
Ten tweede is de ‘foundation' van de webservicesarchitectuur zodanig gemaakt dat het geschikt is voor veilige, betrouwbare en transactionele webservices; kortom geschikt voor bedrijfskritisch gebruik.
XML vormt het fundament waarop zowel de messaging (SOAP) als de metadata (WSDL, Policy) zijn gebaseerd. Over WSDL hebben we al gesproken; het betreft de beschrijving van de functionaliteit van de web service. De Policy (ws-policy) beschrijft de operationele eisen aan de web service. In het vorige artikel noemden we dit het kwaliteitsniveau van de service en de algemene voorwaarden.
Bovenop de basis messaging zijn dan zaken toegevoegd die in de policies worden verordonneerd: de specificaties voor de veiligheid en betrouwbaarheid van de webservices. Boven de foundation bevindt zich het gebied van de applicatie en applicatie infrastructuur: hoe orkestreren we web services tot applicaties, hoe managen we die webservices en hoe linken we het geheel in de business-processen.
Op dit hoogste niveau is het specificatieproces nog in volle gang. Hier hoort ook de standaardisering per industrie. Webservicesarchitectuur richt zich uitsluitend op de syntax van de webservices; de verticale standaards moeten per industrie de semantiek vast stellen.
Figuur 2: Architectuur van webservices
Ten derde, het allermooiste van de webservicesarchitectuur is dat het volledig ‘composable' is, met andere woorden modulair op te bouwen. De figuren 3 en 4 laten dat goed zien. Figuur 3 toont twee plaatjes met een SOAP-bericht van customer naar supplier. Dat bericht is samengesteld op basis van WSDL en bevat het verzoek tot de actie ‘submit_po' (voer inkooporder in) en bevat de gegevens voor die inkooporder zoals klantnummer, productitems, aantal, etcetera.
Het is een basisweb service en ontbeert alle facetten voor bedrijfskritische toepassing. In het tweede plaatje is dezelfde webservice uitgebreid met een policy rondom transacties: de webservice maakt nu onderdeel uit van een business transactie. Aan de service-inhoud zelf is niets veranderd; alleen het kwaliteitsniveau is toegenomen.
Een verdere toename van kwaliteitsniveau zou kunnen plaatsvinden door beveiliging als authenticatie, autorisatie of encryptie toe te voegen. Maar dat kan later eenvoudig worden toegevoegd. Dit composable model maakt dat je met de websservicesbasis kunt beginnen en al naar gelang de behoefte enerzijds en beschikbaarheid van technologie anderzijds het kwaliteitsniveau van de web service kunt verhogen.
Figuur 3: Modulaire opbouw webservices
Figuur 4: Voorbeeld SOAP-bericht
Figuur 4 toont een SOAP-bericht in zijn XML vorm. Daarin is een onderscheid tussen de SOAP-header en de SOAP-body waar te nemen. De body bevat de functionaliteit van de webservice en ontleent zijn compositie aan de WSDL. De header bevat alle policy-gerelateerde aspecten. De SOAP body is verplicht, de SOAP header is optioneel.
In het voorbeeld zijn aan de optionele header de volgende operationele aspecten toegevoegd: adressering, security ( in dit geval een X509 digitaal certificaat) en reliable messaging. Deze drie aspecten staan volledig los van elkaar, er is geen onderlinge afhankelijkheid. Als er nieuwe policy specificaties bijkomen of bestaande wijzigen kunnen deze eenvoudig worden aangepast zonder dat het andere aspecten beïnvloed. Wat een flexibiliteit!
De rol van Microsoft
Microsoft wordt algemeen beschouwd als de trekker van het webservicesinitiatief. Al drie jaar achtereen noemt Gartner Microsoft de leider in hun Magic Quadrant, op korte afstand gevolgd door IBM. Daarachter is een gat geslagen naar de overige deelnemers zoals BEA. SAP, Oracle, HP en SUN.
Microsoft maakte zijn webservicesprogramma publiek in 1999 toen Steve Ballmer sprak over ‘software as a service'. Een jaar later presenteerde Microsoft de .NET technologie en visie. Daarbij liet Microsoft zien dat het een ‘big bet' deed op webservices door alle eigen technologie webservices enabled te maken en het tot in de kern door te voeren.
Het .NET framework is geheel opgebouwd rond XML en webservices. In 2001 startte Microsoft de samenwerking met IBM om de webservicesspecificaties uit te breiden tot aan de webservices architectuur van figuur 3. Dat proces van uitbreiding is tot aan vandaag de dag bezig. Voor elk type specificatie werden de juiste partners gezocht om voldoende kennis en maximale marktkracht te mobiliseren. In 2002 richtte Microsoft samen met IBM, BEA en Intel de WS-I op.
Microsoft is op twee fronten zeer actief. Enerzijds extern door het voortdurend uitbreiden, testen en verbeteren van de web services specificaties totdat ze geschikt zijn om tot standaard verheven te worden. Anderzijds intern door het voortdurend verder ontwikkelen van een platform bovenop het Windows-besturingssysteem dat specifiek gericht is op het ontwikkelen, implementeren en beheren van webservices vanaf het kleinste device (zoals de smartphone) tot en met de hoog schaalbare en beschikbare data center servers.
Het volgende artikel besteedt aandacht aan het complete Microsoft-platform en de strategische initiatieven om dat platform verder te verbeteren en te maken tot de beste, meest complete in de industrie tegen de laagste kosten van bezit. | 
