Service oriented design

Webontwikkeling, je komt er niet meer omheen als modern bedrijf. Of het nu gaat om de bedrijfswebsite, een app waarmee klanten de beschikbaarheid van een product kunnen opzoeken of een online urenregistratie voor personeel, vaak zijn bedrijven bij het laten maken van een webapplicatie overgeleverd aan het technisch inzicht van ontwikkelaars.

Toch is het belangrijk om eisen te stellen aan de manier waarop deze producten worden gebouwd. Deze zogenaamde "software architectuur" is bepalend voor de mate waarin de software kan meeveranderen met de ontwikkelingen van zowel het bedrijf als de gebruiker.

Om dit te verduidelijken wil ik drie software architecturen uitlichten: monolitisch, modulair en service georiënteerd.

Monolitische software

In de meest basale situatie is er weinig structuur te herkennen in de code waaruit de software is opgebouwd. Dit klinkt slecht, en dat is het ook. Maar de praktijk leert dat er veel slechte code is. Enerzijds omdat niet ieder project een goede architect heeft. Anderzijds omdat het veel tijd en moeite kost om bij iedere update de architectuur in het oog te houden.

In dit soort situaties wordt vaak het woord "monolitisch" gebruikt, of "spagetti code", omdat de code dusdanig ongeordend door elkaar loopt dat het een bord spagetti lijkt. Vaak is de opbouw zo slecht te lezen dat zelfs de programmeur die de code geschreven heeft na een tijdje niet meer weet welk stukje code wat doet.

Monolitisch is wat we noemen een "anti-patroon". Maar de meeste services beginnen monolitisch, omdat een prototype zo snel te bouwen is en herbruikbaarheid of leesbaarheid van de code in eerste instantie vaak van ondergeschikt belang is. De meeste services eindigen ook monolitisch, omdat naar mate de verwachte levensduur van de service korter wordt, het belang van onderhoudbaarheid kleiner wordt. Helaas blijkt maar al te vaak dat monolitische services langer gebruikt blijven worden dan de verwachte levensduur en dat onderhoud een zeer tijdrovend en daarmee duur proces wordt.

Modulaire service

In een modulair ontwerp wordt de code opgebouwd uit onafhankelijke brokken, die modules worden genoemd, of libraries, of plugins, of bundles, of nog anders. Deze modules zorgen voor een duidelijke opsplitsing van de code in functionele brokken, dat wil zeggen: iedere module is verantwoordelijk voor een bepaalde functionaliteit.

Het voordeel van modulair programmeren is dat modules kunnen worden hergebruikt in volgende projecten, onafhankelijk van elkaar kunnen worden getest en dat een module, mits de werking ervan goed is gespecificeerd (bijvoorbeeld door een gedefinieerde interface), eenvoudig kan worden vervangen door een andere module die dezelfde werking heeft.

Daarnaast maakt een modulaire opzet duidelijk welk deel van de code verantwoordelijk is voor welke functionaliteit en kan de module onafhankelijk van de rest van de code worden aangepast of vervangen, zo lang de interface maar hetzelfde blijft.

Modules worden vaak gedeeld tussen ontwikkelaars, zodat niet iedereen voor zich weer opnieuw dezelfde functionaliteit hoeft te programmeren. Het voordeel hiervan is duidelijk, maar één van de nadelen is dat er hierdoor ook veel code wordt gebruikt waarvan het vaak niet helemaal duidelijk is wat de code precies doet en wie de code beheert. Dit geldt dubbel voor closed source code (en software).

De meest recente ontwikkeling is dat modules als producten worden gebrand: er wordt zorgvuldig een merk gebouwd om ontwikkelaars ervan te overtuigen dat A dé module is om X te doen. Dit heeft vaak te maken met de interface: de meeste modules voor dezelfde functies zijn namelijk niet precies hetzelfde (vaak simpelweg uit esthetische overwegingen van de programmeur), waardoor degene met de meeste aanhang bepaalt wat de standaard wordt.

Service georiënteerd

In plaats van dezelfde modules voor ieder project weer opnieuw te installeren en te gebruiken, kan er ook worden gekozen voor een andere route, namelijk die van service oriented design. In plaats van een lokale module die functie X uitvoert, wordt een service aangeroepen die functie X uitvoert.

Dit zorgt wel voor meer communicatie over het netwerk, omdat er voor iedere functie berichten heen en weer gaan tussen de services. Vaak kost dit heen en weer sturen ook meer tijd dan een lokale module aanroepen en kan het wel eens mis gaan, bijvoorbeeld omdat de service voor functie X onbereikbaar is.

Het voordeel is wel dat iedere programmeur zich kan focussen op de werking van zijn eigen service en dat iemand anders verantwoordelijk is voor de service die wordt aangeroepen. Ook is het duidelijk wie de aanbieder van de service is en kunnen er dus afspraken gemaakt worden over verantwoordelijkheden.

Daarnaast kunnen meerdere projecten gebruik maken van dezelfde dedicated service, waardoor onderhoud en optimalisatie daarvan de moeite waard kan worden (bijvoorbeeld omdat er per project voor de service betaald wordt) en informatie tussen projecten of producten via de service kan worden uitgewisseld.

Combineren en integreren

Een ander voordeel van service oriented design is dat een services elkaars data kunnen gebruiken en combineren. Denk hierbij bijvoorbeeld aan het analyseren van Twitterberichten om te zien wat trending topics zijn voor een bepaald bedrijf, of het combineren van weerinformatie en verkoopcijfers om daar relaties tussen te vinden.

Er zijn veel services beschikbaar, sommige gratis, anderen op abonnement. Weerinformatie, verkeersdrukte, social media berichten, adresinformatie, etc. En deze lijst wordt groter en groter, naar mate meer personen en bedrijven hun data beschikbaar stellen middels web services.

De mogelijkheden zijn onbegrensd. Bij APItecture helpen we bedrijven deze mogelijkheden te verkennen en optimaal te benutten.

Ontkoppeling gebruikersinterface

Omdat de functionaliteit geen onderdeel meer is van de applicatie, maar een op zichzelfstaande service, kunnen meerdere applicaties dezelfde service gebruiken. Dat wil bijvoorbeeld zeggen dat het eenvoudig is om een single purpose web app te maken voor een hele specifieke toepassing, zonder dat dit invloed heeft op bestaande apps.

Zo ontwikkelde APItecture Vertrek van Treinen, een mobiele web app die op basis van NS reisinformatie, de tijd en de mobiele locatie van de gebruiker de meest relevante treininformatie laat zien, zonder dat een app gedownload hoeft te worden of er informatie moet worden ingevoerd door de gebruiker.

Businessmodel

Het service oriented design model is niet alleen bruikbaar in webontwikkeling. Steeds meer bedrijven zien in dat ook hun services en interne processen volgens dezelfde principes kunnen werken. Hierdoor kunnen ze een noodzakelijk deel van hun bedrijfsproces ook aanbieden als een dedicated service aan andere bedrijven of deze services outsourcen naar een bedrijf dat zich daarin gespecialiseerd (= geoptimaliseerd) heeft.

(c) 2015 www.apitecture.nl