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.
vrijdag 31 oktober 2008
donderdag 30 oktober 2008
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.
dinsdag 28 oktober 2008
Microsoft Azure
Microsoft heeft Azure aangekondigd. Azure is de cloud van Microsoft. Ziet er interessant uit, vooral ook omdat MS nogal inzet op Model-Driven approaches, met name het Oslo-verhaal.
Dat is potentieel een zeer interessante combinatie: Oslo + Azure. Daar zit in ieder geval ik wel op te wachten,
Dat is potentieel een zeer interessante combinatie: Oslo + Azure. Daar zit in ieder geval ik wel op te wachten,
donderdag 23 oktober 2008
AWS gaat nu echt los, geloof ik
AWS (Amazon Web Services) gaan nu echt los. Er is nu een SLA (99.95% of zo uptime), EC2 is uit beta, er is een Windows image, er komen allerlei consoles, load balancing is verbeterd, en Vogels deelt mede dat Amazon nu ook grote bedrijven als doelgroep heeft.
Tot nog toe zat er wat hobbyistisch aan, maar dat gaat er af.
Ik zit zelf ook met interesse te kijken naar de ElasticFox plug in voor FireFox, die het mogelijk maakt de EC2 image te sturen vanuit de browser.
Tot nog toe zat er wat hobbyistisch aan, maar dat gaat er af.
Ik zit zelf ook met interesse te kijken naar de ElasticFox plug in voor FireFox, die het mogelijk maakt de EC2 image te sturen vanuit de browser.
dinsdag 21 oktober 2008
Silver Bullit revisited
Ik vond deze samenvatting van een panel op OOPSLA. Panels zijn meestal geouwehoer, maar dit is wel aardig, en stipt nogal wat vragen aan waarmee ik mij ook bezighoudt. Bijvoorbeeld Dave Thomas:
"1. People have a “very natural tendency to look for easy answers to hard questions, designing software is hard and it will always be hard.”
2. New technologies are often over-hyped: “they have to kind of paint it as a silver bullet because otherwise people won’t listen.”
3. Desire for people to seek better tools rather than “actually learning the trade.” Dave used the metaphor: “there is an old saying: ‘the poor
workman blames his tools’ - people are poor wfor silver bullets to avoid learning the trade. "
2. New technologies are often over-hyped: “they have to kind of paint it as a silver bullet because otherwise people won’t listen.”
3. Desire for people to seek better tools rather than “actually learning the trade.” Dave used the metaphor: “there is an old saying: ‘the poor
workman blames his tools’ - people are poor wfor silver bullets to avoid learning the trade. "
donderdag 16 oktober 2008
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.
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.
woensdag 15 oktober 2008
Elbot en de Turing-test
http://www.elbot.com/
Dat is Elbot, een robot die er dit jaar heel dicht bij kwam om de Turing test te breken.
Je kunt met Elbot praten, en het lijkt heel erg op een conversatie met mijn broer Kees.
Dat is Elbot, een robot die er dit jaar heel dicht bij kwam om de Turing test te breken.
Je kunt met Elbot praten, en het lijkt heel erg op een conversatie met mijn broer Kees.
woensdag 1 oktober 2008
Microsoft in Amazon's cloud
Abonneren op:
Posts (Atom)