SOA is dood, deel 4

De Stem der Rede zei:

"Ironick zegt: "It is services thinking, as conventionally understood, that led to the mess in which we find ourselves: fragmentation caused by entity-specific (service) interfaces".

Een mooie volzin, maar ik denk dat maar weinigen snappen wat hier wordt bedoeld. Dat het in de de IT moet gaan over "services", dat snappen we. Dat deze services WOA compliant in plaats van SOA compliant moeten zijn, dat kunnen software architecten - behalve elkaar - maar moeilijk uitleggen."

En vervolgens wordt mij om een uitleg gevraagd.

Het probleem zit m hier in het begrip "services". Moet het in de IT om de "services" gaan? Sja, dat hangt af wat er mee bedoeld wordt. In SOA in ieder geval wel: daar zijn de services doorgaans het uitgangspunt voor het ontwerp.

Je wordt verondersteld na te denken over welke services er zouden moeten zijn, en als je die eenmaal hebt bedacht, ze volgens de regelen der kunst(autonomie, stateless, etc, etc) te ontwerpen. Maar hoe bedenk je eigenlijk die services? Dat blijft schimmig. De beste manier is om dat te doen vanuit een objectmodel, waarbij de interfaces tussen de objecten worden getransformeerd naar services. Dit kan, en het werkt, alleen doet bijna niemand het.

In plaats daarvan zit men services uit de duim te zuigen, of ze te ontwerpen op basis van wat op dat moment nodig lijkt vanuit een of ander proces, of (nog erger) op basis van wat een bestaande legacy-component biedt. Het gevolg zijn services die ontworpen zijn vanuit de huidige behoefte of zelfs de behoefte (en de architectuur) van het verleden. De kans dat dit in de toekomst andersoortig gebruik vergemakkelijkt (de belofte van SOA tenslotte) is nihil.

Als dit klinkt als een slecht verhaal: dat kan kloppen, want het is een slecht verhaal.

Bij de WOA (of de ROA, dat is wat mij betreft hetzelfde) ontwerp je vanuit resources, zeg maar de gegevensstructuur. Ook als er geen expliciet object- of datamodel wordt gemaakt, moet je als je RESTful werkt een resource-structuur hebben. En het aardige is dat je daarbij weliswaar heel veel fout kunt doen, maar dat er vrijwel altijd toch een bruikbare structuur ontstaat, waarop de resource-oriented services makkelijk te ontwerpen zijn.

En die resource-oriented services zijn veel makkelijker te gebruiken op een manier die niet is voorzien, juist omdat ze zo simpel zijn: een resource kan op een aantal manieren informatie ter beschikking stellen, je kunt nieuwe informatie erin stoppen, je kunt een nieuwe resource van een bepaald type maken en vullen, en je kunt een resource verwijderen. Dat is het wel zo'n beetje.

Makkelijk te begrijpen, en makkelijk te hergebruiken, aangenomen dat de resource-definitie en -structuur ergens op slaat.

Korte samenvatting: de SOA route vereist teveel kennis en strategie van de IT-experts. Als je een goed model maakt en dat model op de geode manier vertaald in services, gaat het goed. Maar dat doet men dus niet.

De WOA-route is veel meer fool-proof. Daar moet men echt heel erg zijn best doen om er helemaal onbruikbare services uit te laten rollen.

Er zijn nog een paar andere voordelen van WOA/ROA, maar het door Ironick genoemde argument komt op het bovenstaande neer.