I’ve posted some thoughts on the recent W3C Enterprise Services Workshop.

Eric Newcomer succinctly summarizes my position on the history of Web vs. Web services;

But I believe your argument is that the industry went the wrong way from those early days by not recognizing that the uniform interface was part of the required adaptation of traditional middleware concepts to the Web, is that right?

Nicely done, Eric!

It sounds like Sanjiva’s as baffled as I am how we can each hold the positions we do about what seems like a completely trivial point. He responds to my previous piece on the Web being for humans, and writes;

The problem with GET is exactly what Mark points to as its feature: GET is reusable for anything. What does that mean? That means the receipient must be able to deal with anything that comes down the pipe!

Well, if the client receives something it doesn’t understand, it just needs to fail gracefully. Even for the case of a browser, most have a fallback for unrecognized content, permitting the user to save it to disk.

I don’t think this is any different than a Web service client invoking getStockQuote, as it would need code to handle stock quotes it didn’t understand (lest it require upgrading once new forms of quotes are developed in the future).

There’s nothing whatsoever wrong with GET- its a great way to get some information from one place to another. However, if you want to use it for application integration then somene needs to write down what kind of data is going to come back when I do a GET against a URI.

Sure, the publisher has to write it down somewhere. The question though is – because this relates to WSDL’s utility – when the client needs to know it.

I’ve written software to support international-scale data distribution networks, and never during the development of that software did I need to know, a priori, which URIs returned what kind of data. I just used the fact that HTTP messages are largely self-descriptive, and so looked at the Content-Type header on responses, along with some error handling code for dealing with unrecognized media types.

Anyhow, this really gets away from the point of this discussion which was just to point out that moving from getRealtimeStockQuote to getStockQuote to GET doesn’t change anything about whether the returned information (which can be identical in all cases) needs a human in the loop or not.

I wanted to expand a little on my dismissal of Sanjiva’s argument that “The Web is necessarily human centric”.

Sanjiva, in his support for – and authorship of – WSDL, presumably wants to permit developers to publish their own service-specific interfaces, such as ones supporting methods like the canonical “getStockQuote”, or even “getRealtimeStockQuote”. And I’m certain he’d claim that these are very much machine-facing interfaces, since that’s supposed to be the whole point of Web services. So far so good?

So why is a system built around GET suddenly not machine facing? I’ve said before that the one thing that most distinguishes SOA and REST is the uniform interface of the latter; it says , in part, that the more general the operation, the more reusable the interface. In other words, using the example above, getStockQuote is more reusable than getRealtimeStockQuote. Moreover, GET is more reusable than getStockQuote.

By following that logic – that more general means more human-targetted – then one can only conclude that the methods most suited for machine-targetting will be the most specific ones. So never mind getRealtimeStockQuote, we’d need getRealtimeStockQuoteForGOOGonNASDAQ.

Of course, that’s silly. So is the argument that the Web is only for humans. I hope (hah! 8-) that this finally puts that argument to rest (pun intended).

I tried to post this comment to Jorgen’s latest blog entry;

Perhaps if SOA were defined, we’d be able to tell you whether there’s a problem that had a decent SOA based solution! 8-O

All I know is that REST is an *improvement* upon SOA for multi-agency, data-oriented systems. The big win is that REST far better separates interface from implementation than SOA, and is therefore far more loosely coupled.

Unfortunately I received this error in response;

Your comment was denied for questionable content.

8-)

Personally, I like his previous attempt far, far better. Why go for loosey-goosey principles – few of which, AFAICT, are testable – when we all know that constraints define architectural styles? Come on Dave, give people the information they need to be able to say “That is SOA”, and “That isn’t”.

A couple of years ago, Dave pleaded for technical arguments in the REST vs. SOA debate. I’d urge him now to do the same. As an example, perhaps he can explain, in technical terms, how he is able to defend a principle such as “Software should be as loosely coupled as possible to the interface” as well as service-specific interfaces. As I’ve pointed out, those two goals are at direct odds with each other because service specific interfaces fail to separate interface from implementation, and we all know that loose coupling is gained only by separating concerns.

Stu Charlton responds to my comment (and Mark’s) about how Pat Helland did things the hard way in discovering REST in a recent paper of his;

So, while the two Marks are suggesting Pat’s reached REST the hard way, I would suggest this is something he’s been saying for years, […]

That is the hard way! 8-O If Pat’s been unknowingly preaching REST constraints for years, then he’s done it from scratch. That’s a great personal accomplishment of course; I wish I were that smart. But wouldn’t it have been great if he had noticed that what he was talking about was being built out right under his nose for the past 15 years? 8-) I don’t fault him for that any more than I fault the bulk of the industry for also missing it (which is to say, a tiny bit 8-).

Anyhow, hopefully this paper can be the catalyst that helps push the industry towards a better understanding of the power and value of the Web. Of course, it also brings a new perspective to bear on the Web itself, from a seasoned distributed computing veteran, so that can only help Web proponents, perhaps motivating new Web based solutions. At the very least, they’ve got me thinking, which is always good 8-)

Eric, any chance we could get Pat to the workshop?

According to Steve Jones, REST is a career limiting move;

But as with any technical discuss there is another thing that should drive you when you look to your decisions. This is whether you want to get fired for a decision when something goes wrong, and whether you want your skills to be relevant in 3 years time.

That would be funny if it weren’t so sad; completely accurate, yet aimed entirely in the wrong direction 8-(

Sanjiva gave a talk at Google on Web services, which also touched on REST. Unfortunately there’s a lot of misinformation in there about REST, including a statement to the effect of “If you want to sign your message, you can’t use REST” (I don’t think I’m taking that out of context), plus a slide (@ 25:00) that includes the following;

REST vs. WS-* is the wrong battle
- WS-* is used to create Service Oriented Architecture
- REST is used to create Resource Oriented Architecture

When taken together with some other comments, it appears as though Sanjiva sees REST as an alias for HTTP (or perhaps HTTP/URI), which it isn’t of course. He’s certainly entitled to his own beliefs, but I think he would do well to spend a couple of days with his nose buried deep in Roy’s dissertation… and not just chapter 5. Until that happens, I’d personally avoid trying to make conclusions about how these different approaches may or may not relate, or may or may not compete.

Ian Foster writes about OGSA-DAI (Data Access and Integration);

[…] it provides uniform Web Services interfaces to diverse data resources

Neat! That’s so 1990.

How many times do we really need to reinvent the Web, on top of the Web?

All this because of a little confusion over a word. Wow.