REST als enterprise architectuur (2)

Donderdag schreef ik er al kort over. Nu deze aardige aanvulling van de voortreffelijke Stefan Tilkov. Gelijk heeft ie.

Verstandige woorden over REST?

Van Boris Lublinsky. En dat is weer gebaseerd op deze post van Arnon Rotem-Gal-Oz (jazeker).

De laatste zegt:
"Let's look at message exchange patterns for instance. REST over HTTP support the request/reply pattern.
This works extremely well in many business situation. For instance is we have an Order service (or resource for that matter) and we need to calculate the discount for a specific customer we can go to the Customer service and get her current status and check if she a VIP customer, senior citizen etc.
There are, however, places where it doesn't work as smoothly. Returning to our Order, lets consider what happen once the order is finalized and we need to both start handle it (notify the warehouse?) and Invoice it
The order service does not care about these notifications it isn't its business.
My favorite way to solve this is to introduce business events (incorporate Event Driven Architecture) so that the interested parties will get notified. Another common way to solve this is to introduce some external entity to choreograph or orchestrate it (BPM etc.) both options have different constraints and needs compared with REST. In my organization we have a lot of processes that lend themselves to event processing much better than they do REST over HTTP (though the implementation might end up aligned with the REST architectural style - I am not sure yet)"

Hmmm. Waarom is die Order niet geinteresseerd in bijv. de handling in het warehouse of de invoicing?

Ik snap wel dat er situaties zijn waarin REST niet lekker werkt, maar dit is een onzinvoorbeeld.

Java applets en JavaScript

Ik heb me wel eens afgevraagd: waarom zijn de Java applets (de oorspronkelijke claim to fame van Java)  niet de standaard geworden voor code-on-demand? 

Dit is het antwoord van Roy Fielding op die vraag.

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.

Links als objecten

En dan dit pleidooi (via Tim O'Reilly) voor links als first class object. Van Ian Bicking.

Doet denken aan de "smart pointers" indertijd om de persistency laag in OO min of meer transparant te maken.

Leonard Richardson over RESTful

Leuk stukje van Leonard Richradson (via Stefan Tilkov) over REST en de soorten of stadia van RESTful. Maakt op simpele wijze eea duidelijk.

Ik ben ook geneigd te denken dat het belangrijkste van REST die URIs zijn.

Gartner, REST en WOA

Stefan Tilkov meldt dat Gartner de WOA (dat is ongeveer het zelfde als wat ik de ROA noem, geloof ik) omarmt. Hoera!

Is dus bij deze mainstream....

Asynchrone REST

Op zoek naar asynchrone REST kwam ik dit tegen. Aardig stuk.

REST 2

(Dit is ook een test om te kijken of de twitterfeed werkt).

Wat betreft die duistere passage in die post van mark Littke waarover ik gisteren schreef: ik denk dat hij bedoelt dat de te navigeren paden in de resource structuur duidelijk moeten zijn in de representatie die de client terugkrijgt. Een domeinspecifiek object- of datamodel is prima, maar mag niet impliciet zijn, dat wil zeggen: het moet niet nodig zijn dat de client developer a priori weet hoe het "model" in mekaar zit.

REST

Stuk van Mark Little op InfoQ, waarin de hele tijd Roy Fileding wordt aangehaald. 

Hmmmm....

Wat bv te denken van: 

A REST API must not define fixed resource names or hierarchies. Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling]."

Vooral dat stuk tussen die haken, over die resource structuur: ik weet niet zeker of ik he daar wel mee eens ben. Ik ben wel voor die resource structures. 

REST modellering

Hoe kun je een RESTful architectuur modelleren? Met andere woorden: hoe modelleer je resources?

Het belangrijkste punt is dat men zich realiseert dat een resource iets wezenlijk anders is dan een component in de gebruikelijke zin van het woord, en in zeker opzicht ook dan een object. Want componenten worden ontworpen vanuit het beginsel van "information-hiding", en bij objecten zijn we oo kgewend dat te doen. Componenten en objecten stellen aan de buitenkant alleen een interface ter beschikking. De interne gegevens zijn verborgen, evenals de methods. En zowel componenten als objecten schermen het woud van componenten resp. objecten "achter zich" af. In feite zijn ze allemaal Facades (het GoF-pattern). De Law of Demeter schreef voor dat een object niet zomaar referenties naar "achterliggende" objecten mag verschaffen.

Met resources ligt dat iets anders. Ja, je kunt resources zo ontwerpen dat het in feite ook facades zijn, en zo dat ze hun interne informatie volledig verbergen. (Al zal dat leiden tot nogal overladen POST-methods.) Maar resources zijn (ook) "knopen" op het web, en zijn juist bedoeld om navigatie naar achterliggende "knopen" (resources dus) mogelijk te maken.

Bij een (goed ontworpen) object-model is dat trouwens ook zo. Dat is wel degelijk bedoeld om transparant te zijn. En dat is dus een goed begin voor een resource-model.

Dit leidt tot de volgende werkwijze:

1. maak een object-model voor het domein, bij voorkeur met standaard-analysepatronen, bijvoorbeeld door de colors-aanpak te gebruiken.

2. onderzoek welke objecten die in het model worden beschreven resources gaan worden. (In de praktijk zullen ze dat allemaal worden.)

3. maak een pad-onafhankelijke identificatie van die objecten. Bijvoorbeeld: .../{Class}/{object-id}, dus: http://JansenBV.nl/Order/id=12345

4. Onderzoek welke "paden" in het object-model navigeerbaar moeten zijn, en welk deel van het model "publiek" is. Hierop wordt de GET-URI-structuur ontworpen.
(In de praktijk zullen associaties en aggregaties in het model vrijwel altijd "publiek" zijn. Met composities ligt het iets ingewikkelder. Die kunnen "verborgen" zijn. Het is een optie om voor het resource-model een speciale modelvorm (UML Profile?) te maken waarbij de betekenis van de object-relaties (associatie, aggregatie, compositie) op die manier is gedefinieerd.)

5. Onderzoek welke messages (maw: methods aangeroepen door een bepaald object) creatie of deletie (zal wel geen nederlands zijn; bij deze) van een object of wijziging van een attribuut tot gevolg heeft. Hierop moet de PUT/DELETE-structuur worden gedefinieerd.

6. Onderzoek wat er overblijft aan "gedrag" in het model wat niet wordt gedekt doro de GETs, PUTs en DELETEs. Daarvoor worden POSTs ontworpen.

Dit is een begin.

SOA: hoe in te voeren? (2)

Rik schrijft:
"ESB gedreven SOA". Bestaat er dan ook zoiets als "niet ESB gedreven SOA"? Volgens mij niet. Zelfs in een volledig geharmoniseerde en gestandardiseerde wereld zul je altijd berichten moeten routeren, gegarandeerd moeten transporteren en moeten orkesteren. Of zie jij een alternatief?

Ja, ik zie wel een alternatief.

Natuurlijk, dat routeren, transporteren, enzovoort is nodig. Maar is het nodig dat allemaal te integreren in één tool, namelijk de ESB? Die is duur om aan te schaffen, duur om te implementeren, en bovendien proprietary, wat in feite betekent dat het bedrijf in kwestie zich min of meer uitlevert aan de vendor.

Bovendien zijn heel veel van die "luxe" functionaliteiten van een ESB helemaal niet zo hard nodig, en worden ze zelden gebruikt.

Door dit alles worden die ESB-implementaties noodzakelijkerwijs company-brede projecten, en zoals we allemaal weten: die mislukken, zeker als ze niet 100% nodig zijn. En dat zijn die ESB-projecten niet, omdat er altijd een plan B is: een beetje halfwas invoeren, en de rest naar de toekomst schuiven. En plan C is: installeren, roepen dat je het gebruikt, maar in werkelijkheid gewoon de ouwe trouwe messagebroker blijven gebruiken.

Ik zie zeker twee alternatieven.
1. gebruik een mean&lean "ESB" voor de routering etc van het berichtenverkeer, en gebruik daarvan de functionaliteit op een dusdanige wijze dat je kunt switchen naar een ander tool. Een manier om dat te doen, is het gebruik van meer dan één ESB, maar dat stuit uiteraard nog wel eens op investeringsgrenzen.
2. gebruik een REST-route, en ga naar een ROA-architectuur. Dat kan ook, daar is nauwelijks extra tooling voor nodig, en kan incrementeel worden gedaan. Maar het sluit (in ieder geval op het eerste gezicht) veel minder goed aan bij de bestaande architectuur, en bovendien weten systeemarchitecten e.d. nit hoe ze dit moeten aanpakken.

Een extra argument voor deze alternatieve routes is dat de ver-SaaS-ing of ver-cloud-ing van de functionaliteit eraan komt, en dan zit een zware proprietary ESB ontzettend in de weg, zowel technisch als budgettair.

Niet doen dus, het zijn dinosaurussen.

REST en gedistribueerde objecten

Ik heb wat lovende reacties gekregen voor een eerdere post over REST. Dank daarvoor.

Maar ik heb ook wat misverstanden geschapen, geloof ik.

Is REST de opvolger van Java voor zover het de implementatie van het object-model betreft? Nee. REST is wat mij betreft alleen de implementatie van de structuur van het object-model: de samenhang tussen de grof-granulaire domein-objecten, en voor de communicatie tussen die objecten.

Althans: voorzover ze op het Web zijn gedistribueerd.

Dus de "binnenkant" van de objecten zal met een andere taal, Java, of Python, of Ruby, of voor mijn part Cobol, C of Erlang, worden geimplementeerd. En als de de objecten niet gedistribueerd behoeven te zijn, maar alleen maar "lokaal" in een applicatie worden gebruikt, is REST ook overbodig.

Maar ik denk wel dat die grof-granulaire objecten steeds meer (ook) als zelfstandige entiteiten op het Web beschikbaar moeten zijn, dat wel.

En ik denk ook dat REST niet het eindpunt is. Daarvoor is REST te weinig passend op wat je echt wil. Niet alleen is de "fit" met object-modellen niet 100%, maar vooral ook het feit dat het communicatie-protocol HTTP is, levert beperkingen op.

Natuurlijk is volgens de REST-adepten juist het gebruik van plain HTTP het grote voordeel, en ze hebben in veel opzichten gelijk. Maar bijvoorbeeld asynchroniteit zit niet in HTTP. Dat betekent dat als asynchrone messages nodig zijn (en dat is bijna altijd zo), dat moet worden opgelost binnen de resources of althans binnen de server die de resources beheert.

Een gestandaardiseerde abstractielaag bovenop REST, waarbij de URI-structuur in stand blijft, prettig zou zijn. Komt zo dan toch weer WS-* via de achterdeur binnen? Nee, dat is niet de bedoeling. Veel WS-* standaarden hebben op zichzelf nut, alleen: de implementatie is zeer toolgebonden, en erg ondoorzichtig.

Ik vraag me af: zou het mogelijk zijn een Erlang-achtige taal te maken die asynchroniteit inbouwt, en gewoon op HTTP is gebaseerd? Of gaat dat toch weer een lekkende abstractie worden?

Representaties

Kees schrijft over REST representaties:
"Goed, het is dus de inhoud (de data) van het object, in een bepaalde
weergave. In OO-talen kan dat meestal niet in één klap zonder
tussenkomst van methods, want daar vindt men dat een object z'n data
moet afschermen en alleen via methods toegankelijk moet maken. Het is
dus zoiets als de method toString van Java. Klopt dat?"

Min of meer.

Ja, een representatie is een weergave van de resource op een of andere manier. In HTML, met plaatjes, alleen een bepaald deel van de info geselecteerd, een bepaalde volgorde, enzovoort.

En inderdaad schermt het begrip "representatie" de resource af van de buitenwereld. Strikt genomen weet je van een resource niets anders dan welke representaties eruit kunnen komen, en weet je dus ook niets van de binnenkant. (Maar dit is inderdaad wel nogal strikte theorie, omdat een netwerk van resources zelf al een sterke semantiek heeft. Als je niet weet wat een bepaalde resource voorstelt, heeft RESTful werken niet zoveel zin.)

Als je om een representatie vraagt (via de GET), roep je inderdaad een method aan, nl de GET, met eventueel parameters in de URI. Wat dat betreft is de REST-implementatie minstens zo OO als de meeste OO talen.

Te vergelijken met toString? Ja, ik denk het wel. Maar de gemiddelde GET voegt wel veel meer semantiek toe.

Representaties

Kees schrijft:
"Wat is een "representation" van een object? Werkt het als een referentie naar dat object, kun je het bijvoorbeeld op die manier veranderen, of is het alleen data en niet het object zelf?"

Goede vraag. Het begrip "representation" binnen REST is inderdaad wat schimmig. Het is een view op een object, maw: een set gegevens, in een bepaalde formattering. Een weergave van iets in HTML is een representatie, de verzameling van orders gesorteerd op datum ook, enzovoort.

In feite is het begrip "representation" de afscherming van de inhoud van een object binnen de context van REST. Informatie vraag je aan een resource via de GET, en wat je krijgt is (per definitie) een representation.

De representation is dus alleen data, en niet het object/resource zelf. Daarvan, of althans: van de resource, heb je de URI. Je kunt de URI kopieren, maar niet de resource zelf.

Het is ook goed om in de gaten te houden dat de begrippen "object", "message", "reference", enzovoort eigenlijk vreemd zijn aan REST. Daar gaat het over "resources", "representations", "URIs". Je kunt (zie eerdere post) wel een zinnige projectie van de OO-begrippen naar de REST-begrippen maken, maar daarmee wordt het nog niet hetzelfde.

Wel denk ik dat het zinnig is de begrippensets wat beter op elkaar te laten passen. Bijvoorbeeld: in REST gebruik je de URI zowel voor resource-identificatie als voor (in OO-termen) parameter passing. Dat kan, het heeft voordelen, maar het zijn voor elk zinnig mens wel verschillende dingen. (Het is ook wel grappig om te zien in welke bochten de REST-puristen zich wringen om deze twee dingen in essentie toch wel hetzelfde te laten zijn.) Het zou helpen als er een duidelijke conventie of desnoods standaard was welk deel van de URI locatie is, en welk deel parameter passing.

Ik rest mijn case

In de zgn. REST-SOA-discussie lopen allerlei vragen door elkaar heen: hoe makkelijk moet een protocol zijn? hoe erg is het om ingewikkelde tools, zoals ESBs, nodig te hebben? heb je bijvoorbeeld transaction awareness nodig? enzovoort.

Dat zijn allemaal interessante en ook relevante vragen, maar ik denk dat het toch vooral om iets anders gaat, namelijk de manier waarop je objecten (en daarmee semantische modellen) kunt gebruiken op het Web.

Toen zo'n 20 jaar geleden OO doorbrak, werd hoog opgegeven van de voordelen: je maakte een model in objecten van het relevante domein, je implementeerde dat in een daartoe geëigende omgeving, en het werkte. Schaalbaarheid, onderhoudbaarheid, en wat niet al waren je deel.

En dat kon dankzij het feit dat goed ontworpen objecten een unieke identiteit hadden en vindbaar waren op een unieke lokatie, ze stelden functionaliteit beschikbaar via een interface, en de interne implementatie en gegevens waren afgeschermd van de buitenwereld. Objecten waren eigenlijk zelfstandige entiteiten die elkaar kennen en met elkaar samenwerken.

Natuurlijk bleek de werkelijkheid wat prozaïscher, en kon er erg veel misgaan. Maar desondanks: als eea goed werd aangepakt, konden de beloften worden ingelost. Althans: binnen de run-time omgeving van een OO-omgeving, bijvoorbeeld een SmallTalk-image. En dus: eigenlijk slechts binnen het geheugen van een applicatie en zolangs als die applicatie loopt.

Persistentie en distributie verstoorden dus de OO-droom, en maakten het nodig om ingewikkelde oplosssinngen te bedenken, waarmee verzekerd werd dat objecten bewaard en geditribueerd konden worden, en wel op een "transparante" wijze. En dus werd er heel wat afgemapt.

Het persistentie-probleem is min of meer opgelost. Er kwamen OO-databases die het applicatiegeheugen en de "echte" database naadloos ("transparant", jazeker) in elkaar over lieten lopen. Erg mooi, en vrijwel niemand gebruikte het. Maar ook de wat meer aardse oplossing via een ORM (object relational mapping) bleek na wat vijven en zessen goed werkend te krijgen.

Het distributie-probleem bleek persistenter. :) Hoe moest de "ruimte" van objecten in één applicatie op één machine worden uitgebreid naar andere ruimtes van andere applicaties op andere machines? Met andere woorden: hoe maken we van al die ruimtes één grote ruimte?

De meest voor de hand liggende oplossingsrichting was: maak bovenop het netwerk een protocol wat ervoor zorgt dat objecten war dan ook elkaar kunnen kennen en direct boodschappen sturen. Java RMI is van deze route een voorbeeld.

Dat werkte, althans tot op zekere hoogte. Binnen een closely-knitted LAN was het netwerk stabiel genoeg om van het netwerk te kunnen abstraheren. Maar daarbuiten bleek dat een fictie: het netwerk was niet stabiel genoeg, en dan kun je het ook niet transparant maken. Bovendien waren de RMI-objecten niet echt persistent, omdat ze in feite afhankelijk waren van de applicatie waarbinnen ze bestonden. En tenslotte was de bovenop het netwerk vereiste laag dusdanig ingewikkeld dat het nooit een algemene standaard kon worden. En dat is ook niet gebeurd: RMI kun je alleen binnen de Java-architectuur gebruiken, en die is niet universeel.

Men kon er niet onderuit: het was niet mogelijk om een werkend object-netwerk te maken volledig geabstraheerd van het netwerk. Dus werd het begrip "component" (opnieuw) ingevoerd. Componenten waren entiteiten die op het netwerk draaiden, en als zodanig bekend waren, en via een functioneel interface aangeroepen konden worden.

Maar hoe verhielden de componenten zich tot de objecten?

Een eerste schot was: laat elk object, althans elk zelfstandig domeinobject, een component zijn. Maar er zijn verschrikkelijk veel domeinobjecten. Die allemaal een echte zelfstandige component maken zou veel te veel resources vergen. Immers, de functionaliteit die nodig is om iets een zelfstandige, vindbare, persistente eintiteit op een netwerk (een component dus) te maken, is fors.Dus moest er een oplossing worden bedacht waarin de object-componenten weliswaar algemeen bekend en bereikbaar waren, maar voor de standaard-component functionaliteit gebruik maakten van een soort component voedingsbodem.

De J2EE-EntityBeans waren een poging in deze richting, maar al ras bleek dat zelfs in deze aanpak veel te veel componenten ontstonden om een acceptabele performance te halen. Bovendien konden J2EE-componenten alleen goed met J2EE-componenten praten, dus van een universele ruimte was sowieso geen sprake. En vergelijkbare nadelen golden voor andere pogingen in deze richting zoals COM/DCOM.

Goed, objecten konden dus niet allemaal componenten worden. Dan maar een hybride benadering: we hebben componenten, en daarbinnen leven objecten. En we gaan een standaard ontwikkelen volgens welke componenten met elkaar, in via die route gedistribueerde objecten met elkaar, kunnen praten. En dat niet gebonden aan één talomgeving (zoals bij RMI). Dat was Corba.

Ingewikkeld? Ja, en ook nog eens slechts een standaard, nog geen implementatie. En je had er meestal dure en in ieder geval moeilijk te begrijpen tools voor nodig.

Een andere variant was: laten we het niet te ingewikkeld maken. We zien de componenten gewoon als objecten (ze hebben tenslotte al een unieke lokatie, en een interface met mooie functies, en we proberen zo'n beetje de OO-ontwerp principes voor het ontwerp van die componenten te gebruiken. Daar is weinig op tegen, en als er goede standaarden zijn of komen voor de communicatie tussen de componenten, dan heeft dit een goede kans van slagen. O ja, en heel belangrijk: we noemen het anders, dan lijkt het nieuw.

Ziedaar SOA, en dankzij XML, SOAP en de WS-* standaarden is het inderdaad een behoorlijk succes. En dankzij het Web en HTTP is de ruimte van componenten nu ook universeel.

Maar het lost het oorspronkelijke probleem niet op. Want SOA-services of -componenten zijn geen domeinobjecten, al lijken ze er een beetje op. Eigenlijk zijn we weer terug bij af: we hebben componenten (services) die elkaar kunnen vinden en met elkaar kunnen praten. Objecten bestaan wel, maar zitten binnenin de componenten. En als ee object een boodschap wil sturen aan een object in een andere component, moet eerst worden uitgezocht waar het doelobject zich eigenlijk bevindt, moet de boodschap vervolgens worden vertaald naar een serviceaanroep, moet daarbij worden aangegeven voor welk object de boodschap eigenlijk is bedoeld, en kan daarna de service-aanroep worden gedaan. En aan de andere kant moet de booschap dan weer worden uitgepakt en ontcijferd, en worden doorgestuurd naar het doelobject. Het kan wel, maar het is erg omslachtig. (Al is dat bij gebruik van MDD-technieken midner bezwaarlijk.)

Stand van zaken: we hebben eindelijk een universele ruimte, maar alleen voor componenten. Die gebruiken om echte objecten direct aan elkaar te hangen is niet gelukt, vanwege gebrek aan eenvoud, gebrek aan standaardisatie, en gebrek aan persistentie.

En toen kwam REST.

De resources van REST vormen een universele ruimte, ze zijn (uiteraard) persistent, ze zijn vindbaar en uniek dankzij de URI, het is een bestaande en zeer wijdverbreide standaard (HTTP in feite), en hij is bewezen makkelijk te gebruiken: het hele Web is erop gebaseerd.

Zouden objecten dan te mappen zijn op HTTP-resources?

Op het eerste gezicht is de mapping lastiger dan op RPC-style componenten. Objecten hebben een unieke identificatie ne locatie nodig, en dat biedt de resource inderdaad dankzij de URI. Maar niet elke via een URI te identificeren resource is een echt object, sommige zijn een "representation" van een object, in OO-termen een returnwaarde van een method.

En de REST-methods passen ook niet zonder meer op de methods in een objectmodel. Immers, REST kent slechts een beperkt aantal methods (GET, PUT, POST, DELETE zijn relevant in dit verband). De eerste drie hebben een heel strikte betekenis, en de consequentie is dat extra informatie (parameters in een method van een object) in de URI wordt gestopt. En methods die niet kunnen worden gezien als een GET, PUT of DELETE moeten via POST worden "getruct".

Vanuit OO ziet het er dus op het eerste gezicht niet zo heel goed uit. Maar als je wat beter kijkt, lijkt dat erg mee te vallen. De object-methods uit een goed ontworpen OO-domeinmodel blijken vrijwel alle zonder veel problemen te kunnen worden vertaald naar HTTP-methods.

Maar dan nog steeds: het wringt. HTTP-resources zijn brokken informatie die aan elkaar zij gerelateerd, met verscheidene representaties. Het zijn geen objecten die potentieel een zeer specifiek hebben. Resources hebben juist zoveel mogelijk een standaard-interface.

De claim van REST-voorstanders is dat dat standaard-interface juist een voordeel is. Doordat bijvoorbeeld de betekenis van GET is gedefineerd als: een GET mag een resource niet wijzigen, kunnen HTTP-servers GET-resultaten cachen. En door de simpele method + URI structuur zouden hergerbuikers makkelijker in staat zijn te snappen wat er gebeurt dan als ze bv een WSDL-file moeten lezen voor een SOA-service. Bij REST is de structuur van de resources en de informatie binnen de resources (te verkrijgen als representatie) primair.

In OO is dat van oudsher anders: daar is het functionele interface primair, en de informatie is juist geëncapsuleerd. Althans: volgens de OO-puristen. Als je kijkt naar een goed domeinmodel, dan blijkt dat veel meer een "semantic web" achtig ding te zijn, waarbij het interface helemaal niet zo'n leidende rol speelt.

(Voor de duidelijkheid: voor OO-toepassingen op een ander nivo dan de implementatie van domeinmodellen ligt dat anders, maar die worden ook niet geraakt door deze problematiek.)

En dus is het verschil met de REST/resource-oriented denkwijze helemaal niet zo groot als het op het eerste gezicht lijkt. En het voordeel van REST, namelijk dat je een universele ruimte met dingen (resources, objecten) krijgt, met unieke locaties, met de mogelijkheid daar via een standaard protocol boodschappen aan te sturen, en dat zonder dat je last hebt van het begrip component, dat voordeel is immens.

Is REST dus de toekomst? Ja, ik denk het wel. Maar we moeten nog wel uitzoeken hoe goed die mapping van OO op REST nou echt werkt, en ik denk dat er toch soort REST-standaard bovenop HTTP (bij via een nadere uitwerking van POST) nodig blijkt. Ook al is dat tegen het zere been van de REST-puristen.

Betekent dit dat "gewone SOA" ten dode is opgeschreven? Dat weet ik niet zo zeker. Voor "semantic web" achtige webservices is REST de eerste keus, maar er zijn ook webservices die andere eisen stellen. In de beruchte WS-* stack zitten een aantal zaken (bijvoorbeeld op het gebied van reliability en security) die wat lastig zijn vorm te geven in een REST-context. Het zou kunnen dat we die veel minder vaak nodig hebben dat we nu denken, maar of dat echt waar is moet nog maar blijken.

Maar er zijn zeker een hoop SOA/SOAP-etc interfaces die makkelijk via REST zouden kunnen werken, en ik denk dat we REST-facades bovenop SOA-interfaces gaan zien. Dat zal de migratie ook makkelijker maken.

Tilkov over REST

Aardig stuk van Stefan Tilkov op InfoQ, met een weerlegging van gangbare argumenten waarom REST niet goed bruikbaar zou zijn voor business services.

Vooral het stukje over transacties en REST is raak, wat mij betreft (punt 6). Tilkov zegt in essentie: inderdaad, met REST is het nauwelijks mogelijk over verscheidene REST services een atomaire transactie te maken. Met WS-AT etc kan dat in theorie wel, maar dan zijn die webservices wel erg strak gekoppeld, en het is waarschijnlijk organisatorisch niet mogelijk, laat staan wenselijk. (Atomaire transacties over grenzen van bedrijven heen? Hoezo loose coupling?)

Het is eigenlijk gewoon slecht design.

REST en de datakoppeling

Eerder schreef ik over de verdediging van de RESTful architectuur door Steve Vinoski.

In dit artikel gaat Steve Vinoski in op het argument dat de standaardisatie van REST interfaces weliswaar standaardisatie op interface nivo oplevert, maar dat het probleem vervolgens wordt verplaatst naar de applicaties, waar de data die met de HTTP-call meekomen, moeten worden geprojecteerd op de "echte" datastructuren.

De RPC/SOAP/WS-*-route probeert die "echte' datastructuren tot een standaard te maken over webservices en componenten heen. Op die manier wordt getracht het Web 'transparant' te maken voro (object-georiënteerde) programmatuur.

Vinoski's argumentatie komt neer op het volgende:
1. RPC/SOAP/WS-* bestrijdt het minder urgente probleem. Wat je nodig hebt voor Web-computing is een protocol wat het mogelijk maakt rekening te houden met schaalbaarheid, latency, caching, etc. REST/HTTP doet dat, door de standaardisatie van methods (GET, PUT, etc), RPC/SOAP/WS-* niet door de proprietary methods.
2. De voordelen van data-standaardisatie werken niet op het Web. Binnen één programma gaat dat wel goed, maar de problemen beginnen al bij een paar componenten die data-structuren delen. Bij deling van data-definties over het Web, over de grenzen van bedrijven en systemen heen, is het een illusie te denken dat er geen vertaling naar de "echte; structuren hoeft plaats te vinden.
3. Juist het feit dat REST het netwerk NIET transparant maakt, maakt REST ontwikkeling makkelijker en robuuster. REST gebruikt de grenzen tussen client en server expliciet: de client krijgt van de server een representatie, en houdt zelf zijn state bij. Dat is duidelijk, helder, makkelijk te bouwen, en robuust.

Ik vind het verhaal van Vinoski overtuigend, in ieder geval waar het gaat om ontwikkeling voor het Web. Binnen de muren van een bedrijf ligt het genuanceerder, maar hoe lang nog zullen we services maken waarvan we zeker weten dat ze alleen in de context van het eigen bedrijf worden gebruikt?

Wel één kanntekening: Vinoski zegt eigenlijk: laten we niet proberen één standaard datastructuur voor bv Employee te hanteren, want dat lukt toch niet. OK. Maar als twee systemen door middel van een webservice communiceren over een Employee, moet wel duidelijk zijn wat een Employee is, wat de betekenis van de attributen is, enzovoort.

Er moet op semantisch gebied dus wel degelijk een overeenstemming zijn, ook als die er op technisch gebied niet is. Vinoski mompelt wat over metadata, maar mompelen lost dit natuurlijk niet op.

Voor het goed werken van webservices inderdaad geen gemeenschappelijk datamodel nodig, laat staan overeenstemming over de technische datastructuren, maar wel een gedeeld semantisch model. Dat is natuurlijk bijna hetzelfde als een gedeeld data- of object-model. Wil dat nou zeggen dat we eerst maar een wereldwijd semantisch model moeten gaan zitten maken, voordat we met het Web en SaaS aan de gang kunnen?

Nee, natuurlijk niet. Zo moeilijk is die semantiek niet, en ik denk dat dat gedeelde model nu al aan het ontstaan is. En als het er eenmaal is, zou je er ook in je interfaces gebruik van kunnen maken.

Een soort semantisch resource-model. Heerlijk......

Steve Vinosky over SOA, REST en serendipiteit

Steve Vinosky maakt een case voor REST als voorkeursstijl van Webservices. Naast de bekende argumenten (hij hamert met name op het caching/scalability-argument), vestigt hij ok de aandacht op de stelling dat REST-services, dankzij het feit dat het om standaard-methods gaat, veel makkelijker vanuit een "onverwachte richting" zijn te hergebruiken dan SOA-stijl services.

Hij noemt dat "serendipitous reuse". En hij stelt dat dit niet alleen voor het Web als geheel geldt, maar ook voor het reuse binnen de architectuur van een onderneming. Hij sluit af met:

"It's highly ironic that many enterprise architects seek to impose centralized control over their distributed organizations. In many cases, such centralization is a sure recipe for failure. A proven framework based on a well-constrained architectural style like REST allows for decentralized development that, because of the architectural constraints, still yields consistency. The Web itself is proof that this form of "control without controlling" works. In the long run, this approach is far more likely to achieve what architects seek than trying to enforce collections of ad hoc governance rules."

Zo.

Heeft ie gelijk? Ik denk dat het in ieder geval voor webservices die publiek zijn, en op het web staan te wapperen naar hergebruikers, wel waar is. En misschien ook wel binnen ondernemingen.

Maar dan moeten die REST-services wel netjes zijn ontworpen. Je ziet nu geregeld GET-commands die eigenlijk een POST-bevatten, of andersom. Dat is niet alleen lastig te begrijpen en dus lastig te hergebruiken, maar bovendien raakt de caching ervan in de war.

Vinosky heeft wellicht gelijk, maar maakt zich wel afhankelijk van het goede design van service-ontwerpers. Zou er een manier zijn om dat in goede banen te leiden, of moeten we hier gewoon rekenen op de natuurlijke selectie?

Want die natuurlijke selectie zal wel werken, op den duur. Als je drie services heb die alledrie hetzelfde doen, en een is met SOAP in de SOA-RPC-stijl ontworpen, een met HTTP, maar met de "verkeerde" method, en een derde netjes volgens de RESTful regels, dan zal op den duur waarschijnlijk de derde het meest worden gebruikt. Ceteris paribus, uiteraard.

En zo verdringt goed design langzamerhand slecht design, en worden de voorbeelden steeds beter.

Tsja, het kan natuurlijk wel effe duren.

REST

Dit is een erg goede introductie voor REST van Stefan Tilkov. Volgens mij slaat hij de spijker op de kop. (Met dank aan Ferrie.)