Platform Strategy & Architecture
« Migrating from Rackspace to EC2Four Principles to Succeed at SOA »

The End of the Web (Style)

  03/20/13 05:50, by jdubray, Categories: SOA

Seven years ago, next month, Tim Bray predicted the End of SOA and concluded his commentary with:

"SOA isn’t the future, Web style is."

That post opened the door to a big circus and gave pundits the "opportunity" to predict with more accuracy than any oracle the Death of SOA. Anne Thomas Manes explained to us in 2009, from the comfort of her cublicle at Delphi Gartner,  that "SOA [was] a great failed experiment". Another "analyst", David Chappell, added to the circus by asking tong-in-cheek "if SOA was failing", and went as far as calling SOA: "Suckered Once Again". Then there was Jim Webber's "Same Old Atrocity" which is one of the most profound and graph-ical presentation IT had ever seen.

How many SOA initiatives were stopped or slowed down by "The End of SOA"? Mine was. My manager at the time told me that Tim Bray's post was circulating in our IT department and he didn't know where to start to craft an answer to his management. His team had built their own ESB at a time when hardly anyone had heard of XML and several years of hard work and constantly rising transaction volumes (a respectable 10 M requests/day at the time, in early 2007)  were now jeopardized by a single paragraph written by Tim Bray. 

Seven years later, the Programmable Web's directory has close to 9000 registered public APIs (yes APIs, as in Ancient Programming Interface). That number is growing exponentially. Out of 9000 APIs, my best estimate is that less than 1% are following Tim Bray's Web Style. They are all but following an "API" style, short of RPC.

If we just take a sample of the newest APIs on the ProgrammableWeb (as of March 18), we have:

  • Ask Ziggy which offers the ability (sic)  to define "actions" (such as Play, NextSong, Previous Song, Shuffle...)
  • WhatLanguage explains that you can use, as you wish, a GET (if your request is less than 7500 chars) or a POST to the same URI to detect the language of a given string
  • actually seem to be offering a Web Style API, but it does not do much, it is simply CRUDing 5 resources (tasks, project, users,...)
  • SkyBuffer is also following the Web Style, but just like, this is just some CRUD on a couple of entities
  • MaShape which is a "Cloud API hub" is very interesting because they offer a better way for developers to consumer APIs. How do they do that? They invite developers to "Learn how to describe your API on Mashape to autogenerate client libraries and documentation". Yes you heard right, after years of bashing, developers start talking about client library code generation.
Why on earth would anyone attempt to build a client library code generation? Wasn't the Web Style all about the "Uniform Interface", Bookmarks and auto-magic HATEAOS? not to forget standard IANA types? Yes, you don't hear that kind of argument much these days. APIs rule. People are no longer ashamed to use a verb in their URLs or POST a (complex) query. Most importantly, MongoDB showed us that there is a lot more needed to CRUD than these 4 little verbs and an anemic URL syntax. Developers and Architects are so desperate to go around the "Web Style" that they even try to add namespaces to JSON. Who would have thought?
You guessed it, the REST emperor has no clothes. That 5 API random sample (out of 9000) from the Programmable Web is actually quite representative of the lay of the land: APIs that do something interesting simply ignore the Web style, APIs that do follow it are just a bunch of boring and useless CRUD while everyone struggles to write API clients since there is no machine readable contract to generate the plumbing. How long does it take to write the client code? A couple hours? a couple days? a couple of weeks? I wrote quite a few, before abstracting it into a Web API client framework. 
For crying out loud, even Swagger's totally gave up on the Web Style in favor of APIs.
After wipping out decades of wisdom in distributed computing architecture from distributed transactions, eventing, orchestrations or assemblies, the Web Style is all but dead. The only people that would argue otherwise are the one that a) that are emotionally or financially attached to it or b) working for a Palo Alto startup which just discovered an nth way to exchange silly pictures and chats. 
Actually, the whole Web is all but dead, between developers who can't figure out how to produce anything of value with HTML5 and compete with Native apps and end users finally getting cold at the wonderful idea of being "the product" central to the Web business model. Tim Berner-Lee which is coming out every six month with a "Long live the Web" message but after a wrath of security abuses, it seems that even a KBE can no longer save the Web. 
The "Web Spring" of 2006, which was launched in the context of a failing SUN (Tim Bray was working for SUN at the time) and a lumping Connected Division at Microsoft, created a big vacuum that was never filled. After chasing the Minimum Viable Architecture, we reached a point where it can't be distinguished from a house of card.  
The truh and the matter is that the Web Style is nothing more than some pitiful CRUD a la SkyBuffer or The "crème de la crème" of our industry lead us into a very big ditch, a pit of technical debt where API providers are now forced to ship client libraries for different platforms like in the old days of ODBC. 
So, where do we go from there? No, I am not suggesting to return to WS-* or even grow REST-*. We have to move forward, passed a corny vision that has plagued our industry since the 70s.
First we have to understand and acknowledge that mobile computing is driving a new paradigm, possibly the biggest paradigm shift in computing we have ever seen. Few people would remember, but software engineering was built on an old, very old paradigm of "file processing" which culminated with UFS. The desktop metaphor and the main usage patterns of PCs remained anchored in "file processing". Mobile is no longer about files, mobile terminals assist us in pretty much any activity we do. If nothing else, future operating systems will be activity centric. Yes, sign of times, even Microsoft finally dropped its stapple folder structure (My Documents, My Pictures , My Music...) or did they?
Second, we have to leave Web technologies behind. They once made some sense when computing was tethered and people could not bring their computing device with them. They no longer do. End users have become far more demanding and sophisticated than developers themselves and thinking that dubious technical arguments can weight in against popular demand is at best naive. The best user experience will win, anyone who has, is or will be betting against it will lose. The Web rose, because it too, once, provided a better user experience. It didn't rise because it was "the Web". 
Third, we have to be pragmatic about distributed computing and continue to unREST. More CRUD is not going to cut it, even with an API as superbly designed as the MongoDB API. We also have to grow up an understand that, OO is the wrong paradigm to represent interactions between distributed components. Hence we have to stop reifying everything we do into stateless singleton method calls. Annotations on a class are simply too weak to drive the semantic revolution that SOA started and we now need to finish.
These evolutions all point to a robust Composite Programming Model where the view and the model are free from each other and hence properly connected, following an activity/action/lifecycle paradigm. Every solution today is a Composite Solution that want to take advantage of the wealth of public or private 2-legged and 3-legged APIs.
Which vendor will take the lead in building a modern composite programming model (CPM :-)? IBM? Oracle? Microsoft? Apple? Google? Facebook? ouch... I would bet on a MongoDB or Joyent style startup which comes out of nowhere and rises at light speed because it delivers a tremendous amount of value.
The Web (Style) isn't the future, a robust Composite Programming Model is.


User ratings
5 star:
4 star:
3 star:
2 star:
1 star:
1 rating
Average user rating:
5.0 stars
Comment from: srini [Visitor]
5 stars

Awesome post! Right On

03/22/13 @ 19:19
Comment from: mark prades [Visitor]
mark prades

OO is the wrong paradigm to represent interactions between distributed components.

So what is the alternative ?


03/26/13 @ 04:22
Comment from: jdubray [Member]  


I wrote several times on that topic. SCA for instance provides a far better approach to distributed systems. It’s programming model includes bidirectional interfaces, orchestration as a service implementation model (nothing to do with BPM), or events.

I also developed something called WSPER in 2007.

If you look at some client code and server-side service implementation they are virtually indistinguishable between JAX-RS and JAX-WS. Why? because they are just some annotations on top of the exact same code. Before you can start innovating at the protocol level, you have to start innovating at the programming model level

03/26/13 @ 05:09




My views on SOA

I work at

Recent projects

the old ebpml

powered by b2evolution

©2017 by Jean-Jacques Dubray

Contact | Help | b2evolution skin by Asevo | blog software | blog hosting