Archetype georienteerde kennismodellering

Al weer enige tijd geleden schreef ik over archetypes en de mogelijkheden om met een archetype-georiënteerde aanpak kennisdomeinen te modelleren, van daaruit software te genereren en bestaande legacy te "harvesten".

Vragen die toen nog niet speelden:
1. is het mogelijk om in plaats van de gangbare OO-modelleringstalen (bv UML) meer SW-achtige talen te gebruiken, zoals OWL of RDF?
(Voorlopig antwoord: ja. Een klein proefje met colors en RDF lijkt goede resultaten te geven.)
2. Hoe makkelijk is het om dergelijke modellen in een ROA of WOA te gieten?
(Voorlopig antwoord: uitstekend! Maar jury is still out.)

Affijn, heerlijke materie, en ik houd u op de hoogte.

Functionele talen, Java en het Web, en het Stockholm-syndroom

Een erg interessant verhaal van de voortreffelijke Steve Vinoski over functionele talen en de manier waarop Java langzaam achter de horizon gaat verdwijnen.

Vooral deze passage:

"Imperative languages such as Java and C++ have come to be known as “high ceremony” languages because of the often mind-numbing amount of syntactic boilerplate and complex object interaction patterns they impose just to get relatively simple applications up and running. Many developers turn to interactive development environments (IDEs) to help them manage this verbosity and complexity, but, in my opinion, this just works around the real problem rather than solves it."

en:

"Using the wrong languages like this can impose a much larger tax on development efficiency than you might realize. Like the proverbial frog in the pot of water on the stove, eventually boiling to its demise as the water temperature slowly increases because it can’t sense the changes until it’s too late, developers who primarily use popular imperative languages like Java and C++ can become so accustomed to the boilerplate, verbosity, and ceremony these

languages require that they simply don’t realize just how inefficient their development efforts really are. Given how defensive such languages’ users can often be, perhaps this form

of programming language loyalty is a less sinister variant of Stockholm syndrome, where captives counterintuitively develop a sense of devotion and emotional attachment to

their captors."

Prachtig! En eerlijk gezegd herkenbaar.

Maar waar het echt om gaat is natuurlijk: zijn die FPs echt beter? Hoe belangrijk is de relatie met REST in dit verband?

Mijn (voorlopig slechts) intuïtie is: ja. Maar hoe verhoudt OO zich tot dit verhaal?

Ja, Java is (min of meer) imperatief, maar dat hoeft niet. Vinoski zelf noemt Ruby, en diezelfde mechanismen ken ik nog van SmallTalk (waar Ruby sterk aan doet denken, uiteraard).

De terugkeer van eiland-automatisering

Dit is een leuk stuk (van Jimmy Nilsson). Goed verhaal, ik zal proberen er op terug te komen.

Essentie: eiland-automatisering, domain-driven, gekoppeld op een slimme manier. Een lied wat ik al lang zing...

Stapelwolken

Volgens dit verhaal kun je binnenkort de GoogleAppsEngine en Salesforce.com aan elkaar koppelen, en bijvoorbeeld gegevens van Salesforce gebruiken in een op GAE gebouwde en draaiende applicatie.

Dat kon natuurlijk eigenlijk al, maar dan moest je op vaak erg ingewikkelde manier die platforms zelf koppelen, en dat deed dus niemand. Want cloud-computing doe je (vooral) om het simpel en goedkoop te houden, en zoiets is allesbehalve simpel en goedkoop.

Voor Google is het natuurlijk heel belangrijk, omdat Google zo beter toegang krijgt tot de zakelijke markt. En voor Salesforce betekent het waarschijnlijk een toevloed van ontwikkelaars, die liever op het veel flexibeler en krachtiger GAE ontwikkelen.

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.

WOA Governance?

Ik kwam (via het onvolprezen InfoQ) dit verhaal tegen van Dan Foody.

Hij pleit voor een soort WOA Governance. Hmmmm, ik weet het niet. Misschien zijn er wel wat dingen nodig en nuttig die hij noemt (bijvoorbeeld versioning), maar om dat "governance" te noemen, is wat misleidend.

Want "governance" heeft de bijsmaak (Dan Foody suggereert dat ook, trouwens) van uitoefening van macht of gezag door "architecten". En dat kan in de WOA-omgevng (want dat is gewoon het Web) niet.

Neemt niet weg dat hij een interessant punt heeft. En daar gaan we over nadenken.

Verstandige taal van Phil Wainewright

zoals gebruikelijk. 

"A constantly recurring theme in the evolution of SOA, cloud and the Web has been the misplaced imposition of trusted, existing structures onto emergent patterns of interaction. This applies with special emphasis to hybrid clouds — build them to fit with your existing, unchanged infrastructure and you’ll get little-to-no benefit. Change your enterprise to really leverage the cloud and nine times out of ten, you won’t have any further use for a hybrid model."