Elektronische diensten: spel om de macht

Dit machtsspel speelt zich af tussen aanbieders, intermediairs en afnemers van elektronische diensten. Een aanbieder biedt elektronische diensten aan die via een intermediair aan afnemers beschikbaar worden gesteld. Een voorbeeld hiervan is te vinden bij woningzoeksites zoals Funda. Een bank in de rol van aanbieder levert bijvoorbeeld een elektronische dienst om een hypotheekberekening uit te voeren. Een webportaal zoals Funda fungeert als intermediair door de dienst van de bank te integreren in het portaal en beschikbaar te maken voor woningzoekenden, de afnemers.
Webservices, remote portlets en widgets verdelen de macht over de gebruikersinteractie van een dienst en het dienstenpalet voor eindgebruikers, op verschillende manieren over de spelers. Bij een keuze voor webservices heeft de dienstaanbieder bijvoorbeeld geen controle over de wijze waarop een gebruiker met de dienst interacteert, in tegenstelling tot remote portlets en widgets. In het geval van widgets bepaalt de gebruiker welke diensten worden ontsloten, terwijl dat de intermediair is in het geval van remote portlets. Om deze machtsverhoudingen te ontrafelen, moeten we iets dieper op de essentiële kenmerken van de technologieën ingaan (zie kader).
Een populaire manier om diensten elektronisch te ontsluiten, is door middel van webservices. Een webservice is in feite een gestandaardiseerde beschrijving waarin een dienstaanbieder beschrijft hoe zijn dienst over internet benaderd kan worden, en welke resultaten worden teruggestuurd. Doordat deze beschrijving eenvoudig opgevraagd kan worden, bijvoorbeeld door een portaal, kan het portaal de elektronische dienst van de dienstleverancier beschikbaar maken voor gebruikers van het portaal. Met webservices is het dus mogelijk een dienst, bijvoorbeeld het uitvoeren van een hypotheekberekening, ‘op afstand’ uit te laten voeren. Webservices nemen verzoeken aan in ruwe data en sturen de resultaten ook als ruwe data terug. Terwijl de dienstaanbieder verantwoordelijk is voor de functie van de webservice, is het portaal verantwoordelijk voor de wijze waarop gebruikers interacteren met de dienst. Dit betekent dat het portaal bepaalt op welke wijze gegevens bij gebruikers moeten worden opgevraagd voordat de webdienst wordt aangeroepen, en hoe de resultaten van de dienst moeten worden getoond. Indien een portaal veel diensten van dienstleveranciers als webservice ontsluit, dan kan dit dus veel werk inhouden voor het portaal. Immers, voor iedere wijziging van de webdienst door een aangesloten dienstaanbieder die van invloed is op de interactie van de dienst, is er een aanpassing van de webdienst nodig.
Kortom, in het geval van webservices hebben dienstleveranciers slechts controle over de functie van de dienst, niet over de interactie met en presentatie van de dienst aan gebruikers. Die macht ligt bij het portaal dat de diensten integreert.
Een remote portlet is een relatief onbekende, maar wel gestandaardiseerde, manier om diensten te ontsluiten. Een portlet is een softwarecomponent die eenvoudig in een webportaal ‘ingeplugd’ en getoond kan worden. Remote portlets zijn benaderbaar over internet. Een portlet die wordt aangeboden door een dienstaanbieder kan als het ware virtueel in een webportaal worden ‘ingeplugd’, waarna de dienst over internet benaderbaar wordt voor gebruikers van het webportaal. In tegenstelling tot een webservice legt een remote portlet niet alleen de functie van een dienst, maar tevens de interactielogica vast. Een dienstleverancier die een remote portlet aanbiedt, is dus niet alleen verantwoordelijk voor de functie van de webdienst, maar ook voor de interactie met de dienst.
In feite vindt er een machtsverschuiving van de verantwoordelijkheden plaats bij het gebruik van remote portlets ten opzichte van webservices. Daar waar het webportaal bij webservices verantwoordelijk was voor de interactielogica, wordt deze verantwoordelijkheid in het geval van remote portlets belegd bij de dienstaanbieder. Daardoor wordt het voor het webportaal eenvoudiger om kant-en-klare diensten te ontsluiten. Het enige wat het webportaal immers hoeft te doen, is de remote portlet ‘inpluggen’ in zijn webportaal. Daar staat tegenover dat het portaal nagenoeg geen controle meer heeft over de wijze waarop de dienst interacteert met gebruikers. Die verantwoordelijkheid ligt nu immers bij de dienstaanbieder.
Widgets lijken vanuit gebruikersoptiek erg veel op remote portlets. Net zoals bij remote portlets leggen widgets zowel de functie als de interactielogica van een dienst vast. En net als bij remote portlets ligt de verantwoordelijkheid hiervoor bij de dienstaanbieder. Het belangrijke verschil tussen beide betreft degene die bepaalt welke diensten ontsloten worden. In het geval van remote portlets is dat de beheerder van het portaal. Die configureert immers welke diensten gebruikers van het portaal voorgeschoteld krijgen. Bij widgets is het de gebruiker zelf die bepaalt welke diensten worden ontsloten. Het portaal biedt slechts een podium om widgets op te kunnen plaatsen, maar het is de gebruiker die bepaalt welke widgets worden geplaatst. Eindgebruikers kunnen dus op eigen houtje een dienst benaderen zonder tussenkomst van het portaal. Een bekend voorbeeld waarin widgettechnologie wordt gebruikt, is iGoogle. Daarmee kunnen gebruikers hun eigen Google-pagina vullen met diensten die ze veel gebruiken, bijvoorbeeld het actuele weerbericht of een kalender.
Zoals bij elk spel is het belangrijk om de belangen van de spelers goed in kaart te brengen. Verschillende belangen kunnen immers leiden tot verschillende technologiekeuzen bij de spelers.
Een belangrijke afweging voor dienstaanbieders is de mate waarin ze controle willen houden over de gebruikersinteractie van een dienst. Als ze die controle zelf willen houden, dan ligt het voor de hand dat ze hun dienst ontsluiten als remote portlet of als widget. Maar als ze hier geen belang bij hebben, dan is ontsluiting door middel van webservices ook een optie geworden. Intermediairs die controle willen houden over de gebruikersinteractie van een dienst, óf die willen beschikken over de ruwe resultaten van een webdienst, zullen louter diensten als webservice willen ontsluiten. Als ze hier geen belang bij hebben maar wel graag het dienstenpalet voor gebruikers willen bepalen, dan valt hun voorkeur op remote-portlettechnologie.
Een andere afweging voor intermediairs is de hoeveelheid werk die ze willen hebben als dienstaanbieders wijzigingen doorvoeren die van invloed zijn op de gebruikersinteractie van de dienst. Als intermediairs de hoeveelheid werk willen beperken, dan zijn remote portlets of widgets voor de hand liggende keuzen. Het gebruikersbelang ligt met name in het al dan niet zelf willen configureren van het dienstenpalet. Als gebruikers dat zelf willen kunnen, dan hebben ze een voorkeur voor widgettechnologie.
Soms zijn belangen van spelers onverenigbaar. Dit kan ertoe leiden dat elektronische dienstverlening tussen de spelers niet goed van de grond komt. Als een speler echter zo machtig is dat hij zijn keuze kan opdringen aan andere spelers, dan is het alsnog mogelijk om elektronische dienstverlening te realiseren.

Lex Heerink is werkzaam als architect en consultant bij onderzoeksinstituut Novay. Daar houdt hij zich bezig met architecturale vraagstukken rondom geïntegreerde elektronische dienstverlening, servicearchitecturen, interoperabiliteit en modelgedreven softwareontwikkeling.