Appstore voor cloud applicaties?

Dit gaat richting een AppStore voor cloud applicaties. Interessante ontwikkeling.

Micropayments bij Google

Dat zat er natuurlijk een keer aan te komen. Maar waarom het nou zo verschillend is van Amazon's FPS weet ik niet.

Wel een interessante move, echter.

REST als enterprise architectuur (2)

Donderdag schreef ik er al kort over. Nu deze aardige aanvulling van de voortreffelijke Stefan Tilkov. Gelijk heeft ie.

Koren op mijn MDD-molen

Als voorstander van MDD is dit (ook van InfoQ) natuurlijk koren op mijn molen.

REST als enterprise architectuur

Het onvolprezen InfoQ heeft deze aardige samenvatting van de discussie of je REST ipv klassieke SOA binnen bedrijven kunt gebruiken.

Mijn mening is natuurlijk bekend, dus laat ik het er nu even bij. Morgen misschien meer.

Virtual private clouds

Een logische ontwikkeling. Zie Amazon en ook OpSource. Je eigen afgeschermde spullen, maar wel op de cloud van resp. AWS en OpSource, met de voordelen van dien.

Het zal koudwatervrees wegnemen, maar ik heb toch de neiging om het als een tussenstadium te zien. Want ik verwacht dat in de meeste gevallen de "echte" cloud toch beter past bij de systemen van de toekomst.

We zullen zien.

IT volwassen?

Volgens Thomas Siebel wel. En dus zijn de tijden van de waanzinngie winsten volgens hem afgelopen. Koren op de molen van Nick Carr (van IT doesn't matter) en de zijnen, waar ik mezelf ook maar toe reken.

Maar wat mij betreft wel een paar opmerkingen:
1. Business-IT is redelijk "volwassen". Dat wordt steeds meer een commodity. Maar ook in commodities is geld te verdienen, soms zelfs veel. Juist hier zal de beweging naar de cloud zorgen voor een grote kostenbesparing voor de gebruikers, maar ook voor veel beweging aan de aanbod-kant. Of dat zal leiden tot enorme winsten is inderdaad de vraag.
2. Er is meer IT dan alleen business-IT. Iedereen roept dan gelijk games en zo, en terecht, maar er zitten nog veel meer dingen aan te komen: semantic web, de mobiele revolutie, etc, etc. Er gebeurt genoeg.

Maar de gouden tijd van de klassieke bedrijfs-IT als moneyspinner zou inderdaad wel eens voorbij kunnen zijn.

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.