Nick Malik is tegen JaBoWS: Just another Bunch of WebServices. Leuke post:
"Tools + existing processes = JaBOWS"
Ik betwijfel of ik zijn enthousiasme voor Enterprise SOA helemaa kan delen, maar hier heeft ie wel gelijk in.
vrijdag 21 maart 2008
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.
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.
woensdag 5 maart 2008
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......
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......
dinsdag 4 maart 2008
User interfaces in de toekomst
Ik denk dat de alomtegenwoordigheid van het Internet en de dalende kosten van hardware ervoor zulen zorgen dat we als standaardinterface niet de universele computer meer zullen hebben, maar in plaats daarvan kleinere, op één bepaalde functie toegesneden, apparaten, zoals de Amazon Kindle, of de iPhone. Binnenin zullen dat soort apparaten wellicht wel degelijk een universele computer zijn, maar het basisinterface is bedoeld voor één functie.
Jon Udell voegt daar een argument aan toe. Hij vindt gewone computer UIs te ingewikkeld, te "metaforisch". En dat is volgens hem een extra voor de kleine UI apparaten: "And if handhelds will become ascendant not only because the devices are mobile, but also because
the interfaces aren't so aggressively metamorphic."
Ik ben het daar wel mee eens.
Jon Udell voegt daar een argument aan toe. Hij vindt gewone computer UIs te ingewikkeld, te "metaforisch". En dat is volgens hem een extra voor de kleine UI apparaten: "And if handhelds will become ascendant not only because the devices are mobile, but also because
the interfaces aren't so aggressively metamorphic."
Ik ben het daar wel mee eens.
Abonneren op:
Posts (Atom)