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."