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.

Wainewright en Smalltalk

Phil Wainewright zingt de lof van Workday.

Hij zegt oa:

"At the core of those new technologies is an object-oriented approach that severs the dependence on SQL database tables at the heart of much of the brittleness of current ERP software. Back in the early 1990s, I worked for a small business owner that wanted to harness the new-found power of SQL query language and 4GL programming languages to build his company’s business systems. The company was a PC reseller, so it wanted to manage customers, orders, sales commissions, suppliers. The first step was to decide in advance how to structure the data: there had to be a table called ‘orgs’ that identified each business the company deal with; and then various tables of the different kinds of business could be joined to the ‘orgs’ table — suppliers, customers and so on.

At the time, this was a breathtakingly elegant and powerful way to map a business’s data. Yet I couldn’t help wondering what would happen if some business need came along that required a table you hadn’t defined into the original SQL database structure. Surely you were building in a significant hostage to fortune?"

En verderop:

"The breakthrough that Workday achieves is to move away from a fixed database structure. The SQL database in a traditional business management application defines the meaning of data into the table structure, and that is its achilles’ heel. Workday’s database tables reflect the needs of the object-oriented application architecture — there are just three tables, for ‘instances’, attributes’ and ‘references’ — and the data and definitions stored in the table are instantiated only when the application runs. The definitions are therefore as easy to change as the data.

When I use terms like ‘instantiated’ I’m slipping into the language of object management. At the heart of Workday is an object management server (OMS) — 30,000 lines of Java code that runs as an Apache Tomcat process, entirely in memory. When the Workday application runs, it scoops up all the data and definitions stored in that three-table database and turns them into meaningful data that can be accessed and manipulated. Changing the business logic — even at a very fundamental level — is simply a matter of changing a few definitions and re-running the application. Workday’s favorite demonstration of this capability is showing how it’s possible to reorganize the structure of your business on the fly, without recoding. In fact, Workday’s application developers never write code. They simply work with the 40 or so object types that have been built into the application, and define and instantiate them as required."

Hmmm, ik weet niet of ik hier zo weg van ben.

Om te beginnen: Phil maakt geen onderscheid tussen twee verschillende rigiditeiten:
1. de rigiditeit die voortvloeit uit de problematische wijzigbaarheid van het model in een 4GL-omgeving. Die was er inderdaad, en voor een deel hing die samen met het feit dat er eigenlijk alleen een datamodel was, waaraan de rest hing.
Het gebruik van oject-modellering lost dat probleem op.
Maar een deel van de moeilijke wijzigbaarheid van een business-model wordt niet veroorzaakt door de modelleertechniek, maar door de aard van het model zelf.
In dit geval ben ik bang dat de Workday-modellen ook niet zo makkelijk te wijzigen zijn. O ja, technisch wel, maar de (semantische) consistentie moet ook verzekerd zijn.
2. de rigiditeit die voortvloeit uit het feit dat tussen het model en de werkende code een compilatie oid. zit. Als dat het probleem is, dan is de oplossing om alles te maken, zoals Workday heeft gedaan, de juiste. Maar is dat het probleem? En is het dan nodig te volstaan met een bare-bones-metamodel met alleen classes, attriuten en relaties?

Zo te horen heeft Workday Smalltalk weer eens uitgevonden. Dat was en is een fantastische taal en omgeving, maar schaalbaarheid was altijd een probleem. En of dat nu zoveel anders is?

Belangrijker: het is niet nodig. Een implementatie bv op basis van de color-modellen zou mooier, minder riskant, en handiger voor het modelleren zijn geweest.

Archetypes (vv)

Ruim twee weken geleden kondigde ik aan te gaan onderzoeken wat het nut is van archetypes, en die te gaan beoordelen op de volgende criteria:
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
En daar kwam later bij:
6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?

De onderzochte aanpakken zijn:
- de REA aanpak (Resources, Events, Agents), in de variant van Pavel Hruby c.s.
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak (pleomorphs) van (o.m.) Arlow en Neustadt.

Ik ben nog lang niet klaar, maar dit is de eerste inventarisatie.

Ad 1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
- REA: ja. Daar is de aanpak bij uitstek voor bedoeld. Het gehanteerde metamodel (REA, duality, conversion process, etc) is ook expliciet uit de abstractie van business-domeinen ontleend (mn uit accounting). De aanpak is compleet: elk business-domein wordt in principe volledig bestreken, zij het dat soms wat kunstgrepen nodig zijn. REA is ook alleen maar voor business-domeinen geschikt.

- colors: ja. De Domain Neutral Component (PPT, Role, Description, Moment/Interval) is een zeer abstract model, en eigenlijk een metamodel dat overal (niet alleen voor business-analyse) kan worden toegepast. Maar er zijn specialisaties mogelijk voor business-analyse, en Coad c.s. geven daarvan ook voorbeelden. De aanpak is compleet: elk business-domein wordt volledig bestreken.

- pleomorphs: ja. De aanpak biedt een set aan (samenhangende) analyse-patronen, die uitstekend geschikt zijn om een business-analyse te doen. Of elk business-domein compleet wordt afgedekt, betwijfel ik.

Ad 2. is de aanpak bruikbaar in een MDE-traject?

- REA: ja, mits verder uitgewerkt. Er zijn iig aanzetten voor MDA/MDE-achtige zaken, maar er zal wel nog het nodige meoten worden gedaan om eea te laten werken. Nadeel is wel dat de REA-aanpak niet uit de hoek van de software-ontwikkeling komt, waardoor de mapping van REA-concepten op bv componenten of classes nog wel eens lastig kan zijn (zie bijvoorbeeld het ontbreken van een Role).

- colors: ja, mits doorontwikkeld. Deze aanpak stamt van voor de MDA-hype, en dus zitten er geen expliciete aangrijpingspunten voor MDA of MDE in. Echter, de aanpak zit zo strak in elkaar als het gaat om de afleiding van modellen dat dit geen groot probleem zal zijn. (opvallend in dit verband is dat Coad c.s. de term "metamodel" niet gebruiken voor hun abstracte patronen, hoewel ze wel bij uitstek zo te gebruiken zijn).

- pleomorphs: ja. Is expliciet opgenomen, en er worden zelfs voorbeelden gegeven met ArcStyler als tool.

Ad 3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?

- REA: waarschijnlijk wel. Echter, de mapping van analyse concepten naar services is nog niet triviaal, mede omdat een REA-model puur op het punt van bv object-orientatie (cohesie interfaces, etc) nog niet helemaal klaar is.

- colors: ja. Weliswaar zitten services etc. niet in de aanpak, maar dankzij de strak uitgewerkte interfaces, de keurig aansluitende domein-concepten en vooral de roles die al in het model als koppeling optreden, is een mapping op een SOA niet moeilijk.

- pleomorhs: waarschijnlijk wel. Deze aanpak resulteert in goede OO-modellen, waaruit services normaliter makkelijk af te leiden zijn.

Ad 4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?

- REA: ja. Ik voorzie geen problemen.

- colors: ja.

- pleomorphs: ja, is er zelfs specifiek op gericht (compleet met voorwoord van de onvermijdelijke Richard Mark Soley, Ph.D.)

Ad 5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?

- REA: zeer twijfelachtig. REA is goed in het adhv de business analyseren van die business, maar is niet gericht op software. Ik betwijfel of dit werkt, al zullen proeven dat moeten uitwijzen.

- colors: ja, uitstekend. De top-down benadering helpt ook bij zeer rommelig in elkaar zittende legacy-software. Colors is eigenlijk een soort patroon-taal, en dat is hier een groot voordeel.

- pleomorphs: ja. Het opzoeken van de patronen is goed mogelijk, maar ze moeten wel al zichtbaar zijn.

Ad 6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?

- REA: redelijk. REA gebruikt expliciet AO voor bepaalde vormen van gedrag (asymmetrische aspecten vooral). Om het echt in een MDE-aanpak te laten werken is nog wel wat werk nodig, maar het begin is er.

- colors: redelijk. Aspecten zitten er niet expliciet in, maar de aanpak (weer dankzij de roles) leent zich er goed voor. Om het in een MDE-aanpak te laten werken is nog wel werk nodig.

- pleomorphs: matig. Voorzover ik kan overzien is er geen rekening mee gehouden. Aan de andere kant; het zijn wel OO-modellen, dus het is er in te breien. Maar er zal meer werk voor nodig zijn dan bij colors.

Zo, dit is de eerste inventarisatie. Het is duidelijk: er is nog veel uit te zoeken. En er is ook nog veel meer te zeggen van deze aanpakken, de voor- en nadelen, enzovoort. Dat zal allemaal gebeuren.