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.
maandag 19 januari 2009
vrijdag 16 januari 2009
SOA is dood, deel 3
De Stem der Rede zegt:
"Het denken in eilanden/domeinen in plaats van enterprise wide is overigens een idee dat ook door de WS-* adepten worden aangehangen. Er lopen dus twee discussies door elkaar: 1) het moet domein gewijs in plaats van enterprise wide; 2) het moet RESTful in plaats van WS-*."
Ja, dat is zo. Maar die twee discussies hangen wel nauw met elkaar samen, in ieder geval volgens de restafari's.
Stel: je wilt "eilandgewijs" ontwikkelen, en je doet dat volgens WS-*. Hoe moeten die interfaces van die eilanden er dan uitzien? Hier zijn 2 mogelijke antwoorden op:
1. je gaat uit van het nu voorziene gebruik van het eiland, en op basis daarvan maak je een interface. Zoals bekend zal je dan niet een interface krijgen wat voor andere doeleinden bruikbaar is dan het oorspronkelijk voorziene doel. Dit zal de bruikbaarheid dus nadelig beïnvloeden.
2. je maakt een of ander model, waarmee je de betekenis voor het te ontwikkelen eiland voor de omgeving beschrijft. Met andere woorden: je brengt de omgeving van het eiland, en daarmee ook de plaatsen voor de zinvolle bruggen, in kaart. Dit is een veel beter idee, maar het nadeel is wel dat je niet alleen het eiland, maar ook de omgeving aan het ontwerpen bent. Dit tendeert dus al snel naar een enterprise-wide ontwerp, zeker als het in het detail moet wat nodig is voor het ontwerpen van WS-* interfaces.
Maakt de introductie van REST dit veel beter? Ja, om een paar redenen.
a. REST dwingt je (min of meer) om een resource-structuur te ontwerpen. Zelfs als je geen idee hebt van de omgeving, krijg je zo toch een ieder geval voor de basale handelingen herbruikbaar interface, ook als dat hergebruik niet plaatsvindt op de voorziene manier.
Anders gezegd: WS-* tendeert naar een functioneel interface, en moet dus ontworpen worden vanuit het nu bekende of voorziene gebruik. REST tendeert naar een interface ontworpen vanuit de resource-structuur (dat komt in de praktijk neer op de logische datastructuur), en dat is veel meer onafhankelijk van het nu bekende of voorziene gebruik.
Natuurlijk is het mogelijk die resource-gerichte aanpak ook in WS-* te gebruiken, maar dan komt het tweede voordeel van REST:
b. REST-interfaces maken gebruik van URI's en de bekende HTTP-methods. Dat is makkelijker te gebruiken dan WS-* interfaces.
Ook dit voordeel is natuurlijk te bereiken in WS-*, alleen: dan heb je REST nagebouwd in WS-*. Waarom zou je dat doen? Dan kun je beter gelijk REST gebruiken, want de voordelen van WS-* boven REST gebruik je toch niet meer.
Dus: WS-* is eigenlijk alleen goed te doen als je een enterprise wide aanpak gebruikt. Als je dat niet doet, zal de herbruikbaarheid zwaar lijden. Bij REST is dat niet nodig. RESTful eilandautomatisering leidt nog steeds tot behoorlijk herbruikbare ontwerpen.
"Het denken in eilanden/domeinen in plaats van enterprise wide is overigens een idee dat ook door de WS-* adepten worden aangehangen. Er lopen dus twee discussies door elkaar: 1) het moet domein gewijs in plaats van enterprise wide; 2) het moet RESTful in plaats van WS-*."
Ja, dat is zo. Maar die twee discussies hangen wel nauw met elkaar samen, in ieder geval volgens de restafari's.
Stel: je wilt "eilandgewijs" ontwikkelen, en je doet dat volgens WS-*. Hoe moeten die interfaces van die eilanden er dan uitzien? Hier zijn 2 mogelijke antwoorden op:
1. je gaat uit van het nu voorziene gebruik van het eiland, en op basis daarvan maak je een interface. Zoals bekend zal je dan niet een interface krijgen wat voor andere doeleinden bruikbaar is dan het oorspronkelijk voorziene doel. Dit zal de bruikbaarheid dus nadelig beïnvloeden.
2. je maakt een of ander model, waarmee je de betekenis voor het te ontwikkelen eiland voor de omgeving beschrijft. Met andere woorden: je brengt de omgeving van het eiland, en daarmee ook de plaatsen voor de zinvolle bruggen, in kaart. Dit is een veel beter idee, maar het nadeel is wel dat je niet alleen het eiland, maar ook de omgeving aan het ontwerpen bent. Dit tendeert dus al snel naar een enterprise-wide ontwerp, zeker als het in het detail moet wat nodig is voor het ontwerpen van WS-* interfaces.
Maakt de introductie van REST dit veel beter? Ja, om een paar redenen.
a. REST dwingt je (min of meer) om een resource-structuur te ontwerpen. Zelfs als je geen idee hebt van de omgeving, krijg je zo toch een ieder geval voor de basale handelingen herbruikbaar interface, ook als dat hergebruik niet plaatsvindt op de voorziene manier.
Anders gezegd: WS-* tendeert naar een functioneel interface, en moet dus ontworpen worden vanuit het nu bekende of voorziene gebruik. REST tendeert naar een interface ontworpen vanuit de resource-structuur (dat komt in de praktijk neer op de logische datastructuur), en dat is veel meer onafhankelijk van het nu bekende of voorziene gebruik.
Natuurlijk is het mogelijk die resource-gerichte aanpak ook in WS-* te gebruiken, maar dan komt het tweede voordeel van REST:
b. REST-interfaces maken gebruik van URI's en de bekende HTTP-methods. Dat is makkelijker te gebruiken dan WS-* interfaces.
Ook dit voordeel is natuurlijk te bereiken in WS-*, alleen: dan heb je REST nagebouwd in WS-*. Waarom zou je dat doen? Dan kun je beter gelijk REST gebruiken, want de voordelen van WS-* boven REST gebruik je toch niet meer.
Dus: WS-* is eigenlijk alleen goed te doen als je een enterprise wide aanpak gebruikt. Als je dat niet doet, zal de herbruikbaarheid zwaar lijden. Bij REST is dat niet nodig. RESTful eilandautomatisering leidt nog steeds tot behoorlijk herbruikbare ontwerpen.
zaterdag 10 januari 2009
SOA is dood, deel 2
Stefan Tilkov geeft zijn mening.
Samenvatting: SOA bevatte veel goede ideeën, maar het idee dat het allemaal in enterprisewide moest is verkeerd. Hij wil SOA als eilandautomatisering, maar dan wel met bruggen: stukje bij beetje, met standaardinterfaces. RESTful dus.
En ik ben het met hem eens, maar dat zal geen verrassing zijn.
Samenvatting: SOA bevatte veel goede ideeën, maar het idee dat het allemaal in enterprisewide moest is verkeerd. Hij wil SOA als eilandautomatisering, maar dan wel met bruggen: stukje bij beetje, met standaardinterfaces. RESTful dus.
En ik ben het met hem eens, maar dat zal geen verrassing zijn.
donderdag 8 januari 2009
SOA is dood
per 1 januari j.l., volgens Anne Thomas Manes. Ik ben het er wel zo'n beetje mee eens, maar die slotconclusie: het gaat om "services" is mij veel te vaag. Daar schieten we niks mee op.
En ik vind haar ook te mild over de claims dat SOA vooral door de organisatie moet worden gedragen, etc. Dat is niet de oplossing, dat is juist het probleem. Organisaties moeten geen IT-architecturen dragen. Als dat nodig is, deugen die architecturen niet.
Aanvulling (via InfoQ): Ironick verwoordt vrij precies hoe het echt zit. SOA wordt ingehaald door het Web, of de WOA, zo u wilt.
En ik vind haar ook te mild over de claims dat SOA vooral door de organisatie moet worden gedragen, etc. Dat is niet de oplossing, dat is juist het probleem. Organisaties moeten geen IT-architecturen dragen. Als dat nodig is, deugen die architecturen niet.
Aanvulling (via InfoQ): Ironick verwoordt vrij precies hoe het echt zit. SOA wordt ingehaald door het Web, of de WOA, zo u wilt.
Abonneren op:
Posts (Atom)