Over REST hebben we het al vaak gehad op deze blog, maar zelden hebben we het gehad over het ware voordeel van dit acroniem: meer nog dan een technologie, is het een architecturaal principe voor het web en voor samenwerkende computersystemen: één dat de data centraal stelt.

Data Centric IT

De meeste informatici weten wel wat data is, en wat databases zijn, maar zijn toch vooral ‘opgevoed’ met een focus op applicaties, algoritmes, enz. De applicatie is uiteraard erg belangrijk: ze verricht het nuttige werk van een computersysteem. Toch moeten we dit nuanceren. Een applicatie is eigenlijk enkel een hulpmiddel voor het manipuleren van de data. Als we er eens bij stil staan, dan komen we tot de vaststelling dat nagenoeg elke applicatie die we kennen, dient om data uit te lezen, in te voeren, mooi/anders weer te geven of te bewerken. Dit geldt zowel voor eindgebruikersapplicaties als voor applicaties die enkel I/O doen (b.v. de zogenaamde ‘batch’ applicaties). Dus eigenlijk is de data de centrale asset van een IT-systeem!

Dan kunnen we ons de vraag stellen of we hier bij het ontwikkelen van de architectuur van computersystemen niet meer rekening mee zouden moeten houden? We kunnen de data voorop stellen als centrale entiteit bij de communicatie tussen verschillende applicaties en gebruikers, en ook binnen verschillende subsystemen binnen applicaties. Doen we dit consequent, dan evolueren we stilaan naar een Data-Centric aanpak van IT.

REST

REST staat als acroniem voor ‘Representational State Transfer’. Deze wijze van data-overdracht heeft een aantal verschillende eigenschappen, waaronder dat men heel eenvoudig via http(s!) en via gebruik van eenvoudige principes als CRUD (Create – Read – Update – Delete) verschillende systemen kan laten communiceren. Voor de rest ga ik hier niet meer verder over uitweiden in deze blog, behalve één belangrijke eigenschap: een goedgemaakte REST API biedt een zelf-descriptief overzicht op data (zogenaamde resources), en niet op methodes. (Voor een mooie en praktische uitleg over REST, kan ik verwijzen naar stackoverflow en ook naar deze leuke.)

Men kan dit principe nog anders uitleggen: de namen die men aan de functies geeft die men in een REST API (Application Programming Interface) kan oproepen om een resultaat te bekomen, zullen geen werkwoorden zijn, maar naamwoorden. Een voorbeeld maakt dit een stuk duidelijker:

Nemen we een applicatie die als één van haar functionaliteiten een lijst van personen/gebruikers beheert. Het is de bedoeling dat andere applicaties personen kunnen zoeken, opvragen, toevoegen, veranderen en verwijderen. In plaats van op de traditionele manier een programmatorische  API of een SOAP (Simple Object Access Protocol) webservice aan te bieden, openen we via een RESTful webservice een raam op de door de applicatie beheerde gegevens. Dit ziet er dan b.v. als volgt uit:

• “GET www.app.be/rest/user”: geeft alle beheerde personen (meestal geeft men daarbij slechts een beperkt aantal gegevens per persoon)
• “POST /user” (we laten het eerste deel van de url vanaf nu achterwege, dit is altijd hetzelfde): laat toe om de gegevens voor een nieuwe persoon door te sturen.
• “GET /user/100023”: geeft detailgegevens over persoon met volgnummer 100023

Het is dus eigenlijk alsof je rechtstreeks in een hiërarchische structuur van je gegevens alle nodige bewerkingen kan uitvoeren. Uiteraard zal de achterliggende applicatie niet zomaar alles toelaten: ze zal nog steeds verantwoordelijk zijn voor controle op input, en voor authenticatie en autorisatie van de systemen die van de RESTful service gebruik maken. De beveiliging in een dergelijke aanpak gebeurt best volgens de principes van Data-Centric Security, daar deze als van nature in een dergelijke Data-Centric Architecture thuishoren.
Uiteindelijk kan veelvuldig toepassen van RESTful principes om applicaties aan te sturen, leiden tot een mooi Data-Centric Ecosysteem, waar de principes van deze architectuur doorgetrokken zijn over een groot aantal verschillende applicaties: In plaats van elke applicatie nog een aparte url te geven, zal men eerder een algemene url opzetten voor de data binnen de gehele groep samenwerkende applicaties (e.g. ‘data.socialsecurity.be’ zou dit kunnen zijn voor alle applicaties binnen de sociale zekerheid). Vele applicaties samen, elk verantwoordelijk voor hun stukje van de hiërarchie, zullen instaan voor deze ene grote RESTful data API, en alle applicaties zullen er op hun beurt weer gebruik van kunnen maken, zonder dat ze zich iets hoeven aan te trekken van waar de data vandaan komt of naartoe gaat (of door welke applicatie ze wordt beheerd). De applicaties hoeven elkaar op deze manier niet meer te kennen of te adresseren; ze hebben enkel het adres nodig van de data. In een enterprise omgeving zal men typisch gebruik maken van een ‘API management suite‘ om zo’n RESTful API, of groep ervan, te beheren.

Men kan het toepassen van dit principe ook zien als een vorm van Data Virtualization, aangezien men services aanbiedt om de data, die normaal gezien in onderliggende databases zit, virtueel te ontsluiten. Indien men deze architectuur via Cloud-technologie implementeert, kan men het ook zien als een vorm van Data-as-a-Service (DaaS). Wanneer men de data ook aanbiedt aan externe partijen, kan het eventueel gaan om Open Data.

Het doortrekken van deze architectuur over de gehele organisatie, of zelfs over meerdere samenwerkende organisaties, kan sterke synergieën teweeg brengen, doordat de data voor alle applicaties éénvormig beschikbaar wordt, en doordat het gemakkelijker wordt om reeds door RESTful services ontsloten data te gaan hergebruiken vanuit meerdere applicaties. Dit leidt uiteindelijk tot wat men noemt, een bloeiende ‘API economy‘. Uiteraard is een goede governance over de data, een Enterprise Information Model, en een sterk Master Data Management van belang om hiermee echt succesvol te zijn.

Communiceren via REST of via EDA ?

Via RESTful services kan je dus in principe alle applicaties die dit vereisen, met elkaar laten communiceren. Dezelfde mogelijkheden heb ik echter eerder al voorgesteld in de context van Event Driven Architecture (EDA) in twee eerdere blogs (basis en geavanceerd). Je kan je afvragen of dit niet redundant is, of welke van de twee nu de beste oplossing is?

Het antwoord is – je had het allicht zien aankomen – dat beide oplossingen hun plaats hebben in een gedistribueerd ecosysteem. Events werken namelijk typisch asynchroon, terwijl REST synchroon kan worden gebruikt. Dit betekent dat een applicatie onmiddellijk op de hoogte kan worden gebracht, indien er een voor haar interessant Event beschikbaar is. Indien de applicatie echter meer data nodig heeft, die zich niet in een beschikbaar huidig Event bevindt, dan kan het deze gaan opvragen d.m.v. het gebruik van een RESTful service. Het besluit is dus dat we Events kunnen gebruiken om nieuwe gegevens zo snel mogelijk over het netwerk te verspreiden, naar alle belanghebbenden, en dat we RESTful services kunnen gebruiken om reeds gekende informatie universeel ter beschikking te stellen op het netwerk, waar alle geïnteresseerden ze kunnen gaan raadplegen. Een mooi complementair geheel dus – en het goede nieuws is dat de beide benaderingen meestal ondersteund kunnen worden door één en dezelfde onderliggende middleware technologie (typisch, de ‘Enterprise Service Bus‘ (ESB) ).

Besluit

Net zoals REST, passen Events heel goed in een Data-Centric Architectuur: Events, zeker business Events, zijn namelijk ook data, en een belangrijke informatiebron voor Analytics. Samen met REST hebben we dus de twee stukken van de communicatiepuzzel binnen Data-Centric IT volledig in handen.