Web Things, by Mark Baker

Needless to say, I’m a fan.

I’ve been thinking about writing this for some time now. In fact, it’s probably way overdue. But there’s no better time than the present, as they say.

I’ve had enough. I’m not participating in any more “REST vs. SOAP” discussions. When I started on this mission to educate those who didn’t understand how the Web could help them, I figured it would be pretty straightforward; I’d explain it, they’d understand, and then we’d all skip away hand-in-hand whistling show tunes. Of course, it didn’t quite work out that way. Instead, I ended up spending on the order of $100K of my own money on travel, as well as the opportunity cost of many hundreds of otherwise billable hours, for what is working out to be essentially nothing in return. If that weren’t enough, my health has suffered the past year or so, in ways I won’t get into here, but that I’m confident are in part attributable to the despair I’ve felt over this extended period of frustration.

The war really has been won, I realize that now. And I’m happy to pat myself on my back for a job well done, despite what it’s cost me. Would I do it over again? No bloody way. I should have just “pulled a Roy” and continued to work with and improve the Web, but restrict my Web services standards work to trying to minimize the harm Web services were doing to the Web (which I was doing, but I went way beyond that). I think Max Planck got it right when he said;

A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.

Oh, and one last thing. I told you so. There, that felt good.

Mark Little responds to an interesting post by Bill Burke about compensation based transactions. I don’t really have any direct response to the gist of that discussion, but wanted to highlight a couple of Mark’s arguments that I consider to be probably the top two arguments by those who feel there’s value in both the Web and Web services (the “fence sitters”, as Mark recalls me calling them 8-).

First up, the belief that the Web has nothing to say about reliability, transactions, etc… Mark writes;

Yes, we have interoperability on the WWW (ignoring the differences in HTML syntax and browsers). But we do not have interoperabilty for transactions, reliable messaging, workflow etc. That’s not to say we can’t do it: as I said before, we did manage to do REST+transactions in HP but it was in a small-scale deployment involving only a couple of partners. There is no technical impediment to doing this: it’s entirely political. It can be done, I just don’t see it ever being done. Until it happens, REST/HTTP cannot compete with the kinds of heterogeneous out-of-the-box interoperability that we have demonstrated with WS-*

I’ve talked about this a lot, most recently in my position paper to the W3C Workshop on Enterprise Services. The gist of the argument is that the Web address all of those needs, just in a way which you might not recognize because it has to address them within the confines of architectural constraints that Web services folks aren’t used to. Again, that’s not to say that every possible one of your needs can be met out of the box today, only that far more of them can than you might believe.

Mark also uses the very common argument that because interoperability requires agreement on data for both Web and Web services, that there’s no significant difference between them (I hope that summarizes his point);

So just because I decide to use REST and HTTP doesn’t mean I get instant portability and interoperability. Yes, I get interoperability at the low level, but it says nothing about interoperability at the payload.

I can’t quickly find any past blog entries that touch on this point (though I know they’re there), but this argument I find the most confusing. I suspect it has to do with what I perceive to be a disconnect between Internet and intranet protocol stacks, but I can’t say for sure.

What Mark calls the “low level” isn’t the low level at all. Assuming he means HTTP, the agreement you get by using it is more (higher level) agreement than you get if you were just using SOAP (or XML-RPC or IIOP or BEEP or …). That’s because you’re agreeing on the methods in addition to an envelope (not to mention many other features).

So that whole “contract thang” has popped up again in the echo chamber. I’m going to pick on Steve Jones a little (more 8-), specifically something he says in his latest piece;

Where I do disagree though is whether this is a good or a bad thing to have these camps. Now I’m clearly biased as I’m on the contract side […]

Hold it! Let’s make sure we’re having the right conversation here. It’s not “pro contract” vs. “anti contract”, it’s simply “many contracts” vs “one contract”.

Resume!

I’m absolutely thrilled that Tim has finally grokked REST. AFAIK, he’s the first die-hard Web services type with a strong public persona to realize REST’s (and the Web’s, of course) benefits over WS/SOA/RPC. Bravo, Tim!

I’ve long thought that what was needed in this discussion was new perspectives on the relationship between REST and WS/RPC/etc… that would permit the message to reach more people. Tim’s ably doing his part along those lines with his followup posts. I would never have thought to describe things this way.

So, who’s next?

I’ll be well out of range of an IP packet next week when it happens, but next Tuesday marks the seventh anniversary of my first public anti-WS post, to Develop Mentor’s old “soap-discuss” mailing list.

I didn’t realize it until now, but James Snell gets the dubious honour of being the target of that post. It’s like he’s Steve Trachsel to my Mark Mcgwire 8-).

That is all.

• Integrate This»Blog Archive » W3C Workship slides online
  My slides from the workshop. Thanks to plh for the PDF conversion.
  (tags: w3c wsec rest webservices soa restvsoa restvsoap)

• IVOA Note – UWS recast as a REST protocol
  Nice description of how to put stuff on the Web that was previously hidden behind SOAP.
  (tags: rest soap webservices http uri)
• Engine of State : On
  Gee, I hope I’m not switching Danny’s lights on and off via GET 8-)
  (tags: rest http web state)
• mnot’s Web log: REST Issues, Real and Imagined
  A nice one from Mark. “The Evils of POST” was a surprise to me though.
  (tags: rest web http)
• The “Q”: The Simplest Distributed Progamming Model
  As a commentor observed “Many a true word spoken in jest… “
  (tags: rest web funny)

• Sanjiva Weerawarana’s Blog – interview on ws-* vs. rest
  “I’m sure I’ll be painted a WS-* fanatic by the RESTafarians now” I think that cat was let out of the bag long ago, Sanjiva 8-)
  (tags: rest wso2 webservices)
• InfoQ: Interview with Sanjiva Weerawarana: Debunking REST/WS-* Myths
  “What about Google maps- is that RESTful? Can you give me the URIs to each and every map block at different resolutions?” Erm, yes. And “The Web is necessarily human centric” I didn’t realize anybody was still saying that!
  (tags: rest webservices restvsoa restvsoap wso2)
• Sound advice: REST in short form
  “REST increases the likelihood that arbitrary components of the architecture can talk to each other”
  (tags: rest)

• JSR 311: Java (TM) API for RESTful Web Services
  Sounds like fun!
  (tags: rest java jcp)
• Fundamentals of Web Site Acceleration :: Port80 Software
  ” Send as little data as possible – Send it as infrequently as possible”
  (tags: web performance http)
• WS-* vs REST is not the question (Eric Newcomer’s Weblog)
  “so any application can be accessed the same way, regardless of its implementation technology. Can’t it?” Yes sirree!
  (tags: rest soa webservices soap restvsoa restvsoap)