I’m disappointed with the responses here. Steve’s an expert technologist in this domain. There’s a real opportunity for learning when the ESB approach is *appropriate* – instead we see the same old reactionary web v enterprise positioning and the usual suspect arguments being rolled out against REST style integration.

Bill’s right; the discussion has unfortunately mostly degenerated into the usual no-light-all-heat “us vs. them” argument. I especially object to the folks who twist what I say and accuse me of saying things that I never even remotely hinted at, but I guess that’s the price of blogging publicly.

I’m not going to try to address the comments individually, especially the ones from the guys who, amusingly, wrote lengthy diatribes explaining to me just what ESBs are, what they’re supposed to do, and why they’re beneficial. Yes, guys, I get all that. Perhaps you should go back and read some of my publications from 3, or 4, or 5 years ago? Funny how I don’t recall any of you being around back then, when I felt more positive about ESBs (hint, it was before that term was coined) and I was blogging and writing to that effect.

Arguing this issue on technical merits is rather pointless. One of the best comments in this thread was from Dan Hatfield:

Honestly, I see the ESB as primarily a political thing. It allows for a greater degree of control on delivered solutions. In large companies, we don’t often do architecture – we do politecture…The politics drive the architecture. Not the way it should be…but that’s the way it is.

So true, so true. Another non-technical way to look at it is from the viewpoint of Clayton Christensen’s classic book, The Innovator’s Dilemma. For quite a few years now, we’ve seen a series of sustaining innovations in the “object/service RPC” line of descent originally popularized by CORBA and COM, both of which built on earlier RPC, distributed object, and TP monitor technologies. RMI, EJB, SOAP, WS-*, and ESB are all offspring in that line, and there are surely more to come. I feel that REST, on the other hand, fits the definition of a disruptive innovation perfectly (and if you’re too lazy to read the book, then please at least follow the link, otherwise you won’t understand this at all). The proponents of the sustaining technologies look at REST and say, “well it can’t solve this and it can’t solve that” and voice numerous other complaints about it, precisely as Christensen predicts they would. But Chistensen also explains why, at the end of the day, any real or perceived technical shortcomings simply don’t matter (and in this case, they’re mostly perceived, not real). HTTP-based REST approaches have a lower barrier to entry and are less complex than anything the sustaining technologies have to offer, and REST is disrupting them, whether all the smart folks pushing ESBs like it or not. It’s not a technical issue, and there’s no amount of technology the non-REST tribe can throw at it to stop it because it’s based on how markets work, not on the technical specifics.

At the end of the day, if you don’t think REST is viable or you don’t like dynamic languages, then don’t use them. It just means that you’re at a different point than I am on the Technology Adoption Lifecycle curve. Like I already said in my first follow-up, I’m not in that business anymore, so it doesn’t matter to me at all. I’ll just keep using what I know to be generally superior to all the other approaches I’ve worked on over the years.

Responses

There’s a quote from Upton Sinclair that Greg Linden used recently [http://glinden.blogspot.com/2007/10/thick-thin-and-office-live.html] that’s mighty applicable to the Innovator’s Dilemma (as well as your earlier comments on development language monocultures) –

“It is difficult to get a man to understand something when his salary depends on his not understanding it.”

I think REST is going to have the same problems as AOP in that it takes days, weeks, months for the concepts to click.

Also, please don’t equate TMs, TP, and EJB, or EJB-like technology with the REST/WS-* debate. All these technologies have a “local” component which fit quite nicely in a RESTful environment. I’ve already done a couple of thought exercises. Even things like BPEL could be salvaged and used with RESTFul web services.

Hi Bill, yes, for some people, it takes awhile for REST to click, and just when you think you totally get it, you find something new to think through. That’s not unusual; if you’re used to thinking about something a certain way, it takes time to retrain your brain to think about it differently.

But once you get REST, you’ll wonder 1) why you ever thought the other approach was the best approach, and 2) how you ever missed REST in the first place. Judging from your blog, I think you’ve been personally experiencing this for yourself lately.

Regarding your comment about EJB and such, note that I said it’s all part of a certain technological line of descent, and I don’t think there’s any denying that WS-* belongs in that same line of descent, whether you personally care for it or not. ;-) But I clearly see your point about the “local” aspect of the technologies you mention, and I agree that they can be very useful as part of a RESTful implementation.

not a web v enterprise positioning protagonist, I don’t believe in either. I took the phd work ages ago and read it on a beach full of great stuff other than PCs. Must have missed something but I agree it

concrete example, how fierce markets work in fact, for REST to be about integration in my case and plenty of others that run and make money, it has to lose the idea that accessibility is the key.

And it has to lose (or better put, accomodate far more than) HTTP for that matter.

The world is full of non-REST systems and baking in some ‘level of depth’ where required simply isn’t practical. I am more afraid it will cause another, gold-rush based on web, marketing and ads.