Artikel


Erik Saaman: Soa - services of architectuur

Erik Saaman

Oorspronkelijk gepubliceerd op www.edusite.nl op 21/03/2007

Soa is hip! Zo erg zelfs dat de meeste mensen met wie ik beroepsmatig te maken heb niet meer spontaan rode oortjes krijgen als de term valt. Voor de lezer die nu nog wel zit te gniffelen: soa staat voor service-oriented architecture. Voor sommigen is de afkorting vooral een ziekte, voor anderen is het juist het geneesmiddel voor alle ict-kwalen. Maar ook hier ligt de grens tussen pijn en genot voor iedereen anders. Een soa-aanpak legt vaak nadruk op het opstellen van een architectuur in combinatie met het gebruik van (web)services. Daarmee wordt onderbelicht dat het soms zinvol kan zijn om services in te zetten zonder een uitgewerkte architectuur op te stellen.

Veel mensen die er iets van moeten vinden, worstelen met de vraag of ze een soa in huis moeten halen. In presentaties over het onderwerp wordt steevast benadrukt dat er heel veel moet gebeuren voordat je een goede soa hebt, dat de hele organisatie bij de ontwikkeling ervan betrokken moet worden en dat je er veel deskundigen bij moet halen. Daar komt nog eens bij dat de korte termijn voordelen weinig concreet zijn. Daar schrikt men van, en terecht. Dit zijn geen goede verkoopargumenten binnen de hoger onderwijswereld. Alsof je iemand die een betere auto wil hebben een hele garage probeert te verkopen. Dan kun je immers zelf je auto verbeteren!

Maar moet het dan meteen zo groots en meeslepend? Kunnen we niet eerst een klein beetje soa doen, zodat we er aan kunnen wennen? Ergens in een hoekje, waar niemand er last van heeft? Uw consultant vindt waarschijnlijk van niet. Maar ik denk dat het vaak wel kan. Het ligt er namelijk maar net aan wat de doelstellingen zijn. Als het doel vooral is om de sterke kanten van verschillende applicaties met elkaar te combineren, ga dan eerst ervaring opdoen met de inzet van webservices.

Het begrip soa kent twee aspecten die we relatief los kunnen benaderen: services en architectuur. Het is heel goed mogelijk met services te werken zonder een uitgewerkte architectuur, en andersom. Ik pleit ervoor soa niet als een alles of niets aanpak te positioneren waarbij men kiest voor 100 procent services en architectuur. De nadruk kan ook op één van twee liggen. Stel webservices centraal als het doel is nieuwe mogelijkheden te creëren door systemen aan elkaar te koppelen, stel architectuur centraal als het doel is het managen van de complexiteit van de ict-infrastructuur. Als beide aspecten in het geding zijn, kies dan een tussenvorm. Bijvoorbeeld door de architectuur stapsgewijs te ontwikkelen en tegelijkertijd steeds services te implementeren.

Met webservices als uitgangspunt richt men zich op het implementeren van koppelvlakken op systemen. Hiermee worden de individuele functies van de systemen zichtbaar en voor andere systemen toegankelijk. Dit is vooral zinvol als het functies betreft die voor de buitenwereld interessant zijn, zoals het aanmelden voor een studie, het opvragen van cijfers, het bestellen van een publicatie, etcetera. Omdat webservices individueel gerealiseerd kunnen worden, is deze insteek relatief goedkoop en is het resultaat direct zichtbaar.

Met architectuur als uitgangspunt richt men zich op het schetsen van een totaalplaatje van systemen en de relaties daartussen. Hiermee worden de overkoepelende bedrijfsprocessen en de inzet van ict daarbij zichtbaar. Dit is vooral zinvol als de onderlinge samenhang van systemen verbeterd kan worden. Bijvoorbeeld door het ontdubbelen van functionaliteit en vereenvoudigen van koppelingen. Omdat architectuur allesomvattend is, is deze insteek relatief duur en geeft het niet meteen zichtbare resultaten. Maar op termijn zal het effect waarschijnlijk juist groter zijn.

Een nadruk op webservices past goed bij de Web 2.0-beweging, waar diensten vaak als webservices beschikbaar worden gesteld. Dit stelt andere dienstverleners in staat eenvoudig nieuwe diensten te creëren door gebruik te maken van deze services. Zoals de woningsite Funda, die op Google Earth het woningaanbod laat zien (zie beta.funda.nl). Zo'n combinatie van diensten wordt wel een mashup genoemd. Naast de nadruk op architectuur, kenmerkt de gebruikelijke soa-aanpak zich door het gebruik van zware (dus dure) technieken. Web 2.0 toepassingen maken meestal gebruik van eenvoudiger technieken.

Op www.programmableweb.com staan veel voorbeelden van mashups en de onderliggende services (daar aangeduid als API's). Een voor het onderwijs relevante toepassing van webservices is de zogenaamde personal learning environment (ple). Dit is een variant op de elektronische leeromgeving (elo) waar Web 2.0 technieken centraal staan. De belofte van een ple is dat deze flexibeler (en persoonlijker) is in te richten dan een tradionele elo zoals Blackboard.

Kortom, stel webservices centraal als het realiseren van nieuwe functies op basis van bestaande systemen het voornaamste doel is. En kies daarbij voor lichtgewicht technieken. Ben ik dan tegen architectuur? Nee, integendeel! Bij een juiste diagnose en mits zorgvuldig aangebracht kan het de jeuk van een te complexe ict-infrastructuur aanmerkelijk verlichten.

Personalia

Erik Saaman is gepromoveerd informaticus, met als specialisme formele talen en software engineering. Bij de Rijksuniversiteit Groningen was hij technisch projectleider voor de introductie van een instellingsbrede elo en content management systeem. Vanaf 2004 werkt hij bij SURFnet aan diverse projecten waarin webservices gebruikt worden.

Soa in het kort

  • Een service is een afgebakende taak die een stuk software voor mij kan uitvoeren. Bijvoorbeeld het bestellen van een boek bij Amazon of het opvragen van mijn tentamencijfers bij het studievoortgangsysteem. Services kunnen via internet aan mensen aangeboden worden, maar ook aan andere computersystemen. Men spreekt dan van webservices. Belangrijk is dat een webservice op een technisch open, liefst gestandaardiseerde manier beschikbaar wordt gesteld. Zo kan elk systeem eenvoudig gebruik maken van de webservices van andere systemen. Bijvoorbeeld om bij een boekenlijst van een online cursus een knop te plaatsen waarmee in één handeling de betreffende boeken besteld kunnen worden. Een voorbeeld van een webservice dicht bij huis is de RSS-feed op de homepage van de EduSite. Hiermee kan een zogenaamde RSS-reader een overzicht tonen van het laatste nieuws op de EduSite. 
  • Een architectuur is de beschrijving van een ict-infrastructuur in termen van losse componenten en de onderlinge koppelingen daartussen. 
  • Een service-oriented architecture is een architectuur waarbinnen de componenten met elkaar samenwerken door middel van webservices.

Oorspronkelijke reactie op EduSite:

Ik denk dat Erik gelijk heeft. Een SOA kan met webservices geimplementeerd worden, en in de praktijk zullen ook veel van de services door software geleverd worden. Maar je kunt SOA ook invoeren zonder webservices door service bijvoorbeeld handmatig te implementeren.

Je kunt heel natuurlijk heel goed met webservices aan de slag zonder meteen een SOA in huis te halen of zelfs een komplete Enterprise Architectuur je organisatie binnen te rijden. Webservices en SOA staan dus los van elkaar. Er is dus helemaal niks tegen om ergens onder een bureau wat te knutselen met webservices. Er zijn al voldoende appplicaties (Question Mark Perception met QMWise, het LearneXact LCMS, Sharepoint, de Ephorus plagiaatdetektie e.d.) die functionaliteit (services) aanbieden in de vorm van webservices.

SOA is een vorm van Enterprise Architectuur. En ook een bedrijfsarchitectuur hoeft je niet meteen groots en meeslepend in te voeren. Dat is waarschijnlijk een garantie voor mislukking. Stap voor stap, passend bij de heersende bedrijfscultuur en het 'corporate IQ'. Van kleine experimenten tot instellingsoverstijgende inzet (3TU) Een proces dat zich uit kan strekken over enige jaren.

Daarvoor is echter wel enige visie en regie nodig. Maar dat is een ander verhaal :-).

Eelco Laagland, senior medewerker ICT en Onderwijs, Universiteit Twente.

REACTIES


Geen reacties gevonden.

PLAATS REACTIE