Phil Wainewright luidt het jaar uit

Met het stellen van een paat stevige opvattingen: Cloud delusions, oftewel: misvattingen over cloud computing en SaaS.

Ik ben het vrijwel van A tot Z met hem eens. Een beetje cloud computing heeft weinig zin.

Productiviteit van programmeurs

Er zit een groot verschil in productiviteit van programmeurs. Maar vreemd genoeg zie je dat over het algemeen niet erg terug in de beloning. Dit verhaal van John Cook gaat daarover.

Stof tot nadenken.

Dood paard

SOA als dood paard bij Geek and poke. Erg leuk.

(Hat tip Jan L.)

Spot market bij AWS

AWS verkoopt nu EC2 capaciteit op een soort spot market: je geeft aan hoeveel je wilt en tegen welke maximum prijs. AWS bepaalt de prijs op basis van de vraag en de beschikbare capaciteit.

Schitterend: Amazon kan zo nog beter de capaciteit optimaliseren, en dus goedkoper maken (of winstgevender), en de klant krijgt capaciteit voor een lagere prijs, als ie genoegen neemt met een lagere prioriteit.

Dit soort innovaties maakt de cloud goedkoper. En dat is wellicht de belangrijkste drijfveer om over te stappen.

SPDY, Google en HTTP

SPDY is een soort uitbreiding van HTTP, voorgesteld door Google om het Internet sneller te maken. Het gaat dan met name om de latencies die door HTTP worden veroorzaakt.

SPDY draait gewoon bovenop TCP, en is niet zozeer een vervanging van als wel een aanvulling op HTTP. GET en POST, en ik denk ook PUT en DELETE, blijven gewoon bestaan.

Whitepaper is zeer goed leesbaar en begrijpelijk.

We zullen zien wat er van komt.

Event-based programming de nieuwe GOTO?

Kreet klinkt goed. Of het ook ergens op slaat weet ik niet, moet ik even over nadenken.

Maar de template "a is nieuwe b" ben ik iha nogal een voorstander van. "Java is het nieuwe Cobol". :) Iedereen in de gordijnen.

15 jaar Design Patterns

Naast de Val van de Muur nog een verjaardag: 15 jaar Design Patterns. Hier paar aardige stukken daarover.

Was het inderdaad (ook) een revolutie? Mwah, nee. Het was een erg goed idee, een stap in De Juiste Richting, etc, etc, maar een revolutie? Nee. Eigenlijk bestonden design patterns al, ook in de softwarebouw, maar we noemden ze anders.

Een sorteeralgoritme of een Balance-Line constructie uit de Jackson hoek zijn niets anders dan design patterns. En in beide gevallen ook keurig beschreven, met indicaties, contra-indicaties, voorbeelden, en wat niet al.

Dus nee, geen revolutie.

Waarom het toen zo'n enorme ophef teweeg bracht heb ik toen niet begrepen, en naderhand eigenlijk ook niet.

Maar dat neemt niet weg dat het een mijlpaal was.

RDBMS bij Amazon

Amazon AWS brengt nu naast de al bestaande key-value database ook een RDBMS (My SQL) in de cloud. Ik ben er wel blij mee.

Uit de email aan de klanten:

"We are excited to announce the public beta of Amazon Relational Database Service
(Amazon RDS), a new web service that makes it easy to set up, operate, and scale
relational databases in the cloud. Amazon RDS gives you all the features and
capabilities of a MySQL database, while managing time-consuming database
administration tasks and providing the cost-efficiency of running in the AWS cloud.
We're also excited to announce lower prices for Amazon Elastic Compute Cloud (Amazon
EC2) instances and a new family of Amazon EC2 High-Memory Instances, tailored for
customers wanting to run their own large databases and other memory intensive
applications. To get started using Amazon RDS, High-Memory Instances for Amazon EC2,
and other Amazon Web Services, visit http://aws.amazon.com

Amazon RDS provides a fully featured MySQL database, so the code, applications, and
tools that you use today with your existing MySQL databases work in Amazon RDS
without modification. The service automatically handles common database
administration tasks, such as setup and provisioning, patch management, and backup.
You also have the flexibility to scale the compute and storage resources associated
with your database instance through a simple API call. "

MDSD en DSLs

Goed stuk van Markus Voelter.

Amateur cloud

Goed stuk van de voortreffelijke Phil Wainewright. Bestaande datacenter oplossingen zomaar in the cloud zetten werkt niet.

Rik in de cloud

Rik Laurens meent: SOA en WOA komen elkaar tegen in de cloud, en hebben elkaar nodig. het is moeilijk het hiermee oneens te zijn, maar ik ga het denk ik toch proberen.

Maar eens een nachtje over slapen.

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.

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

Wolfram Alpha

Een nieuwe search engine, maar geen Google-imitator. Klinkt goed, lijkt het soort vragen te beantwoorden die ik graag stel.

E-books en de toekomst

Steven Johnson in de WSJ over hoe de komst van e-books veranderingen teweeg zal brengen. Volgens mij zit ie behoorlijk goed.

Oracle koopt Sun

Een paar punten uit de losse pols:

1. de aankoop van Sun door Oracle is volgens mij op de eerste plaats
defensief. Oracle drijft of dreef op licenties voor on-site software
(mn de Oracle DB en het ERP systeem). Door de komst van SaaS en cloud
computing staat dat onder zware druk. Door de aankoop van Sun
diversificeert Oracle.

2. Sun heeft een goed cloud aanbod, de Sun Cloud. Dat kan Oracle
kansen bieden in de cloud computing markt. en daarmee het verlies van
de licentie-inkomsten enigszins compenseren.

3. Sun heeft de ws. gevaarlijkste concurrent van het Oracle
DB-systeem: MySQL. Ik ben benieuwd wat Oracle daarmee gaat doen.
Afsplitsen?

4. Sun is de eigenaar van Java. Zal Oracle ook dat gaan afsplitsen?

5. Met de aankoop van Sun koopt Oracle de mogelijkheid om het bedrijf
een andere richting (cloud computing, hardware, OS-produkten) in te
laten slaan. Maar of dat gaat lukken, betwijfel ik. Er zijn niet veel
voorbeelden van bedrijven die zichzelf met succes zo fundamenteel
heruitvinden.

DSLs

Aardig stuk van Vaughn Vernon over DSLs. Legt o.a. verschil tussen interne en externe DSLs uit.

Twitter revolutie in Moldavië

Hoe de revolutie of wat het ook is in Moldavië ondersteund wordt door Twitter. (via Nick Carr).

einde gratis Web in zicht?

Dit stuk is wel een beetje paniekerig, maar logisch is de ontwikkeling wel: tot nog toe kon het Web parasiteren op de content van media als kranten en TV-stations, die op hun beurt die informatie van persbureaus als AP haalden, en daarvoor betaalden.

Maar die kranten vallen om, en de TV-stations krijgen het ook moeilijker door het teruglopen van de advertentie-inkomsten. En dus lopen de inkomsten voor AP c.s. terug, en dus gaan ze proberen geld te verdienen aan publicatie op het Web.

Groot gelijk, wat mij betreft, al weet ik niet of het zal lukken.

Internet in een zeecontainer

Laat ze gaan, gaan, gaan,
geef die jongens toch ruim baan
al gaan
ze soms ook niet zo snel
douw een op je rem
denk af en toe aan hem
de containers, ze moeten erdoor!

(Henk Wijngaard, uit mijn hoofd)

Mooie plaatjes: de SUN containers.

Zon schijnt door de wolken

Sun's cloud. Ze bieden voor storage (o.a.) de S3 API aan.

O ja, en dan dit gedoe over dat Cloud Computing Manifesto. Moet ik nog een post aan wijden.

Betalen op het Internet

De laatste tijd is er erg veel discussie over hoe informatie op het Web betaald moet worden. Door de crisis komt er sneller een einde aan de VC-pot dan (waarschijnlijk) gedacht, en de advertentie-inkomsten lijken ook terug te lopen. Deels door de crisis, maar ook door autonome oorzaken. (Ik heb daarover eerder geschreven, oa hier.)

En in dit stuk betoogt Eric Clemons vanuit een andere invalshoek dat advertenties op het Internet niet een blijvende bron van inkomsten voor content kunnen zijn. Kern van zijn redenering: advertenties vervelen en irriteren, en consumenten hebben andere, betere manieren om te vinden wat ze nodig hebben. Dus werken advertenties niet (meer).

Clemons ziet wel wat in micropayment (hoewel hij wel erg makkelijk over de bezwaren heenstapt), en vooral in paid access.

Interne "clouds"

Rik zegt:
"Wat is er 'cloud' aan een enterprise cloud? Behalve mogelijk een stuk virtualisatie dat we al jaren kennen.

De crux van cloud is (mede) multitenancy. En dat zie ik een enterprise cloud niet gebeuren."

Ik ben het wel met Rik eens, al kun je een betoog ophangen dat je binnen zeer grote systemen ook een soort van multitenancy zou kunnen hebben. Bedoeld wordt dat je dezelfde technieken, misschien zelfs dezelfde protocollen, gaat gebruiken. En dat zal inderdaad leiden tot gebruik van een externe cloud, dat ligt in de lijn der verwachtingen.

Enterprise clouds

Over interne clouds voor ondernemingen.

Er wordt ook gezegd dat het waarschijnlijk een tussenfase is in het proces naar het uitbesteden van de IT aan de "echte" cloud.

Ik vraag me af of het vanuit kostenoogpunt te rechtvaardigen stap is; misschien voor grote ondernemingen wel.

Java applets en JavaScript

Ik heb me wel eens afgevraagd: waarom zijn de Java applets (de oorspronkelijke claim to fame van Java)  niet de standaard geworden voor code-on-demand? 

Dit is het antwoord van Roy Fielding op die vraag.

Niet gratis

Dit is mij uit het hart gegrepen. David van 37signals die vindt dat het eigenlijk heel gewoon zou moeten zijn als een gebruiker betaalt voor dingen die hij doet via het Web.

Server oligopolie

Opmerkelijk: volgens dit verhaal in de FT wordt zo'n 20% van de server computers gekocht door een handjevol cloudleveranciers (Rashid van MS noemt met name Amazon, Google, Microsoft en Yahoo). Die enorme infrastructuur is zich aan het vormen zonder dat we het echt zien.

(via Nick Carr).

Opera schaft de stack af

Volgens dit verhaal gaat Opera om de browser te versnellen met registers ipv de stack werken. Keren oude tijden terug?

RDBMS vs. key/value

Tony Bain over RDBMS vs key/value-bases. Goed stuk.

Wainewright over platforms

Interessant verhaal van Phil Wainewright.

Vooral: "I suspect the root of the problem in Sage’s case was an unthinking assumption that Aqualogic was such an established Web platform that basic security would just be built in as standard. This is typical of the blind-leading-the-blind nature of the on-premise software model, in which customers blithely believe that vendors have built everything they’ll need into the platform, while vendors naively assume that anything they’ve missed will be easily spotted and corrected by customers during the implementation process. It’s bad enough when it results in catastrophic roll-outs at just a single company, but when the application is being deployed as a service to multiple downstream customers, a far higher duty-of-care is required, because the risk exposure is massively amplified."

SOA is dood, deel 4

De Stem der Rede zei:

"Ironick zegt: "It is services thinking, as conventionally understood, that led to the mess in which we find ourselves: fragmentation caused by entity-specific (service) interfaces".

Een mooie volzin, maar ik denk dat maar weinigen snappen wat hier wordt bedoeld. Dat het in de de IT moet gaan over "services", dat snappen we. Dat deze services WOA compliant in plaats van SOA compliant moeten zijn, dat kunnen software architecten - behalve elkaar - maar moeilijk uitleggen."

En vervolgens wordt mij om een uitleg gevraagd.

Het probleem zit m hier in het begrip "services". Moet het in de IT om de "services" gaan? Sja, dat hangt af wat er mee bedoeld wordt. In SOA in ieder geval wel: daar zijn de services doorgaans het uitgangspunt voor het ontwerp.

Je wordt verondersteld na te denken over welke services er zouden moeten zijn, en als je die eenmaal hebt bedacht, ze volgens de regelen der kunst(autonomie, stateless, etc, etc) te ontwerpen. Maar hoe bedenk je eigenlijk die services? Dat blijft schimmig. De beste manier is om dat te doen vanuit een objectmodel, waarbij de interfaces tussen de objecten worden getransformeerd naar services. Dit kan, en het werkt, alleen doet bijna niemand het.

In plaats daarvan zit men services uit de duim te zuigen, of ze te ontwerpen op basis van wat op dat moment nodig lijkt vanuit een of ander proces, of (nog erger) op basis van wat een bestaande legacy-component biedt. Het gevolg zijn services die ontworpen zijn vanuit de huidige behoefte of zelfs de behoefte (en de architectuur) van het verleden. De kans dat dit in de toekomst andersoortig gebruik vergemakkelijkt (de belofte van SOA tenslotte) is nihil.

Als dit klinkt als een slecht verhaal: dat kan kloppen, want het is een slecht verhaal.

Bij de WOA (of de ROA, dat is wat mij betreft hetzelfde) ontwerp je vanuit resources, zeg maar de gegevensstructuur. Ook als er geen expliciet object- of datamodel wordt gemaakt, moet je als je RESTful werkt een resource-structuur hebben. En het aardige is dat je daarbij weliswaar heel veel fout kunt doen, maar dat er vrijwel altijd toch een bruikbare structuur ontstaat, waarop de resource-oriented services makkelijk te ontwerpen zijn.

En die resource-oriented services zijn veel makkelijker te gebruiken op een manier die niet is voorzien, juist omdat ze zo simpel zijn: een resource kan op een aantal manieren informatie ter beschikking stellen, je kunt nieuwe informatie erin stoppen, je kunt een nieuwe resource van een bepaald type maken en vullen, en je kunt een resource verwijderen. Dat is het wel zo'n beetje.

Makkelijk te begrijpen, en makkelijk te hergebruiken, aangenomen dat de resource-definitie en -structuur ergens op slaat.

Korte samenvatting: de SOA route vereist teveel kennis en strategie van de IT-experts. Als je een goed model maakt en dat model op de geode manier vertaald in services, gaat het goed. Maar dat doet men dus niet.

De WOA-route is veel meer fool-proof. Daar moet men echt heel erg zijn best doen om er helemaal onbruikbare services uit te laten rollen.

Er zijn nog een paar andere voordelen van WOA/ROA, maar het door Ironick genoemde argument komt op het bovenstaande neer.

SOA is dood, deel 3

De Stem der Rede zegt:
"Het denken in eilanden/domeinen in plaats van enterprise wide is overigens een idee dat ook door de WS-* adepten worden aangehangen. Er lopen dus twee discussies door elkaar: 1) het moet domein gewijs in plaats van enterprise wide; 2) het moet RESTful in plaats van WS-*."

Ja, dat is zo. Maar die twee discussies hangen wel nauw met elkaar samen, in ieder geval volgens de restafari's.

Stel: je wilt "eilandgewijs" ontwikkelen, en je doet dat volgens WS-*. Hoe moeten die interfaces van die eilanden er dan uitzien? Hier zijn 2 mogelijke antwoorden op:
1. je gaat uit van het nu voorziene gebruik van het eiland, en op basis daarvan maak je een interface. Zoals bekend zal je dan niet een interface krijgen wat voor andere doeleinden bruikbaar is dan het oorspronkelijk voorziene doel. Dit zal de bruikbaarheid dus nadelig beïnvloeden.
2. je maakt een of ander model, waarmee je de betekenis voor het te ontwikkelen eiland voor de omgeving beschrijft. Met andere woorden: je brengt de omgeving van het eiland, en daarmee ook de plaatsen voor de zinvolle bruggen, in kaart. Dit is een veel beter idee, maar het nadeel is wel dat je niet alleen het eiland, maar ook de omgeving aan het ontwerpen bent. Dit tendeert dus al snel naar een enterprise-wide ontwerp, zeker als het in het detail moet wat nodig is voor het ontwerpen van WS-* interfaces.

Maakt de introductie van REST dit veel beter? Ja, om een paar redenen.

a. REST dwingt je (min of meer) om een resource-structuur te ontwerpen. Zelfs als je geen idee hebt van de omgeving, krijg je zo toch een ieder geval voor de basale handelingen herbruikbaar interface, ook als dat hergebruik niet plaatsvindt op de voorziene manier.

Anders gezegd: WS-* tendeert naar een functioneel interface, en moet dus ontworpen worden vanuit het nu bekende of voorziene gebruik. REST tendeert naar een interface ontworpen vanuit de resource-structuur (dat komt in de praktijk neer op de logische datastructuur), en dat is veel meer onafhankelijk van het nu bekende of voorziene gebruik.

Natuurlijk is het mogelijk die resource-gerichte aanpak ook in WS-* te gebruiken, maar dan komt het tweede voordeel van REST:

b. REST-interfaces maken gebruik van URI's en de bekende HTTP-methods. Dat is makkelijker te gebruiken dan WS-* interfaces.

Ook dit voordeel is natuurlijk te bereiken in WS-*, alleen: dan heb je REST nagebouwd in WS-*. Waarom zou je dat doen? Dan kun je beter gelijk REST gebruiken, want de voordelen van WS-* boven REST gebruik je toch niet meer.

Dus: WS-* is eigenlijk alleen goed te doen als je een enterprise wide aanpak gebruikt. Als je dat niet doet, zal de herbruikbaarheid zwaar lijden. Bij REST is dat niet nodig. RESTful eilandautomatisering leidt nog steeds tot behoorlijk herbruikbare ontwerpen.

Cobol op de cloud

MicroFocus zorgt ervoor dat je op Amazon EC2 Cobol kunt draaien.

SOA is dood, deel 2

Stefan Tilkov geeft zijn mening.

Samenvatting: SOA bevatte veel goede ideeën, maar het idee dat het allemaal in enterprisewide moest is verkeerd. Hij wil SOA als eilandautomatisering, maar dan wel met bruggen: stukje bij beetje, met standaardinterfaces. RESTful dus.

En ik ben het met hem eens, maar dat zal geen verrassing zijn.

SOA is dood

per 1 januari j.l., volgens Anne Thomas Manes. Ik ben het er wel zo'n beetje mee eens, maar die slotconclusie: het gaat om "services" is mij veel te vaag. Daar schieten we niks mee op.

En ik vind haar ook te mild over de claims dat SOA vooral door de organisatie moet worden gedragen, etc. Dat is niet de oplossing, dat is juist het probleem. Organisaties moeten geen IT-architecturen dragen. Als dat nodig is, deugen die architecturen niet.

Aanvulling (via InfoQ): Ironick verwoordt vrij precies hoe het echt zit. SOA wordt ingehaald door het Web, of de WOA, zo u wilt.