Jagen op de perfecte SOA
Het nadrukkelijke gebruik van standaarden maakt het ontwikkelen van herbruikbare software (bijvoorbeeld in de vorm van services) makkelijker, maar vanzelf gaat het natuurlijk niet: de ontwikkelaar zal expliciet aandacht moeten schenken aan het toekomstvast maken van zijn ontwerp. Als dit niet gebeurt, zijn we nog verder van huis dan ‘alleen maar’ terug bij af: de extra investeringen die gedaan zijn om de SOA neer te zetten, zijn weggegooid als de basis niet toekomstvast is neergezet.
Dit artikel presenteert zeven stellingen met als strekking dat de jacht op de perfecte SOA vereist dat er op diverse gebieden expliciet aandacht wordt geschonken aan toekomstvastheid.
Mats Brinkman (mats.brinkman@ordina.nl) is ICT-consultant bij Ordina. Dr. Jan-Willem Hubbers (jan-willem.hubbers@ordina.nl) is Solution Architect bij Ordina.
SOA overstijgt projectscope
Een projectteam dat een service moet opleveren, heeft vaak de beschikking over een beperkt budget en staat onder hoge tijdsdruk. Het is aantrekkelijk om een goed werkend product op te leveren dat alleen geschikt is voor de gevraagde situatie.
Het is goed mogelijk dat buiten de projectcontext een soortgelijke service gebruikt zou kunnen worden. Als deze bredere context niet meegenomen wordt in het ontwerp, wordt de toekomstvastheid van de service geweld aangedaan: door de beperkte opzet is de geleverde service alleen voor de gevraagde situatie geschikt. Het gevolg is dat er onnodige kosten worden gemaakt voor uitbreidingen, of dat verschillende services ontstaan die ongeveer hetzelfde doen. Van de tijd en het geld die bij de eerste service zijn bespaard, is nu een veelvoud nodig om de nieuwe services te maken en te onderhouden.
Het is dus belangrijk een overzicht van potentiële serviceafnemers te hebben, ook al vallen deze niet allemaal binnen de projectscope. Op deze manier kunnen verschillende eisen en wensen worden gecombineerd, wat resulteert in een oplossing die ook voor toekomstige afnemers bruikbaar is.
Een werkend tool maakt nog geen toekomstvaste SOA
Leveranciers van SOA-tools hebben het meeste inzicht in de sterke en zwakke punten van hun eigen tools. De kans is groot dat hier in projecten dankbaar gebruik van wordt gemaakt. De focus van een leverancier is echter vaak meer gericht op het werkend krijgen van het eigen product of het verkopen ervan, dan op het realiseren van een toekomstvaste SOA-oplossing. SOA is meer dan verschillende applicaties met integratietooling op elkaar aansluiten; toets als architect de oplossingen van een SOA-leverancier op toekomstvastheid.
POC geslaagd, SOA mislukt
▪ Namespaces
Namespaces worden gebruikt om uniek te verwijzen naar namen van elementen en attributen die in berichtuitwisseling worden gebruikt. Zo wordt voorkomen dat er meerdere definities van hetzelfde element gebruikt worden. Door in een bericht een element vooraf te laten gaan door een namespace, wordt het in een context geplaatst. Op deze manier worden ambiguïteiten en de daaruit volgende ‘spraakverwarringen’ in de berichtuitwisseling uitgebannen. Zeker als services ook gebruikt worden door externe partijen is het gebruik van namespaces noodzakelijk voor betekenisvolle communicatie.
De namespace wordt geïdentificeerd door middel van een Uniform Resource Identifier (URI). De URI wordt opgebouwd uit een authority (de organisatie die de definitie beheert), gevolgd door een zogenaamde route die het mogelijk maakt om de namespace onder te verdelen in domeinen (voor een totaalbeeld, zie: http://organisatie.nl/domein)
SOA eist testen onder de motorkap
Services vormen de verbindende schakel tussen applicaties, maar ook tussen bedrijven, domeinen, rekencentra en besturingssystemen. Door op een standaardmanier te testen, ontstaat geen volledig beeld van de werking van een service. Op het oog goed werkende services blijken in een achterliggend systeem verkeerde of onvolledige acties uit te voeren.
Een SOA-tester gaat verder dan het testen van de gebruikersschermen van een applicatie. Hij volgt berichten op verschillende plekken in de Enterprise Service Bus (ESB), bijvoorbeeld binnen ‘queues’ van een messagingsysteem, en controleert dat een goede melding op een scherm ook leidt tot de juiste actie in een achterliggend systeem. Selecteer als projectmanager dus testers die niet alleen vertrouwen op documentatie en die niet bang zijn om de motorkap open te doen: toekomstige gebruikers kunnen een bestaande service op een andere manier gebruiken dan de huidige gebruikers.
SOA kan niet zonder CDM
Om te onderzoeken of een gekozen oplossingsrichting in de praktijk ook echt werkt, is een van de eerste stappen in een SOA-traject vaak een ‘proof of concept’ (POC). Om de POC zo representatief mogelijk te maken, worden vaak services gebouwd die qua functionaliteit bruikbaar zijn voor de rest van de organisatie. Het is dan van belang om trouw te blijven aan het idee achter de POC, namelijk dat deze een of meer aspecten van de gekozen oplossingsrichting test, en geen bulletproof services realiseert die direct in beheer en in productie genomen kunnen worden.
Zodra de POC succesvol afgerond wordt, is er vaak al vraag naar de gebouwde services vanuit andere projecten/organisatieonderdelen. Als deze services overhaast in productie worden genomen, blijkt pas achteraf dat de aspecten die in de POC (terecht) niet meegenomen zijn nu een fiks struikelblok vormen omdat niet voldaan wordt aan bedrijfsstandaarden op het gebied van beveiliging, foutafhandeling, beschikbaarheid, performance, naamgeving en documentatie. Behalve dat het in productie nemen van een dergelijke service voor de hand liggende (maar verbazingwekkend vaak genegeerde) risico’s met zich meebrengt, zijn ook de voorwaarden geschapen om deze service in toekomstige projecten links te laten liggen.
Architectuur voorkomt de volgende generatie legacy
Voor een zinvolle uitwisseling van berichten is het nodig dat zender en ontvanger dezelfde betekenis hanteren voor de uitgewisselde gegevens. Applicaties en afdelingen binnen een organisatie gebruiken verschillende benamingen (bijvoorbeeld ‘achternaam’, ‘naam’, ‘geadresseerde’) voor hetzelfde concept, of verstaan allemaal iets anders onder hetzelfde begrip (de ‘klant’ van de CRM-applicatie is anders dan de ‘klant’ van de financiële applicatie). Zoals een ESB op technisch niveau een ontkoppelpunt vormt tussen applicaties, kan een Canoniek Datamodel (CDM) semantisch een ontkoppelpunt zijn. Het CDM legt vast wat de betekenis is van alle gegevens die in berichten uitgewisseld worden. Zonder CDM kan de eerste generatie services weliswaar sneller gerealiseerd worden, maar doet geen recht aan het SOA-concept van ‘loose coupling’.
Zonder documentatie geen SOA
SOA wil nogal eens vanuit de technische kant van een bedrijf starten. Technisch staat niets het in isolatie bouwen van een service in de weg. Bijvoorbeeld omdat er geen richtlijnen zijn waaraan men zich moet houden, of omdat het in verband met tijdsdruk ‘beter’ uitkomt om ze te negeren.
Het negeren van architectuurstandaarden resulteert in een service die niet voldoet aan de standaarden van een bedrijf, en daarmee niet toekomstvast is. Er ontstaat een wildgroei van oplossingen, bijvoorbeeld rond de structuur van namespaces, met betrekking tot de manier waarop foutafhandeling wordt geregeld, of naar aanleiding van de precieze semantiek van de berichten die worden uitgewisseld.
Dit kan op korte termijn succesvol lijken, maar door de gebrekkige toekomstvastheid van de ontwikkelde services is er nieuwe legacy gebouwd in plaats van herbruikbare SOA-bouwstenen.
Betrek om dit te voorkomen vanaf het begin een architect bij het project: hij kan zorgen voor uniforme kaders en richtlijnen over projecten heen, zodat toekomstig hergebruik beter mogelijk is.