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
maandag 29 september 2008
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.
"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.
vrijdag 26 september 2008
SOA: hoe in te voeren?
Jonathan Mack op InfoQ, over hoe moeilijk het is om SOA in te voeren.
"When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:
"...to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it’s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB) - the ability to translate and transform information from one system to another and the ability to route messages - as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations."
Ja, zo ken ik er ook nog wel een paar. Dit is dus ook een moeizaam verhaal.
Conclusie: SOA, althans ESB gedreven SOA, werkt niet.
Misschien wat kort door de bocht, maar eigenlijk komt het daar wel op neer. Zie ook dit en dit.
"When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:
- Enterprise (top-down) SOA approach, which is an extremely high - risk approach with an initial price tag of a several million dollars. In addition, based on the size and complexity, such project can virtually never be accurately estimated.
- Grassroots (bottom-up) SOA approach - implementing elements of SOA (both services and infrastructure) as parts of existing business-driven IT undertaking. This approach typically does not succeed. On one hand, the scope of resulting services is limited to the specific business problem and might not be applicable (or even wrong) for the rest of enterprise. On another hand, the time and expense required to build the SOA layer can detract from other business needs of a project."
"...to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it’s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB) - the ability to translate and transform information from one system to another and the ability to route messages - as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations."
Ja, zo ken ik er ook nog wel een paar. Dit is dus ook een moeizaam verhaal.
Conclusie: SOA, althans ESB gedreven SOA, werkt niet.
Misschien wat kort door de bocht, maar eigenlijk komt het daar wel op neer. Zie ook dit en dit.
vrijdag 19 september 2008
O'Reilly gelooft ook niet in het advertentie-model
donderdag 18 september 2008
Content delivery door Amazon AWS
Kijk, dit zat er in: content delevery via één API door AWS. Koppeling met het betaalsysteem FPS ligt natuurlijk vreselijk voor de hand.
Zie AWS blog en Werner Vogels.
Abonneren op:
Posts (Atom)