Web Things, by Mark Baker

According to Jon Udell, extremism is dead. How silly! Sometimes, whether you know it or not, the truth is not shades of grey that requires finding a middle ground, it’s boolean. Take REST vs. Web services, for example. REST is a simply a superior architecture by all important measures, than what people know to be Web services (the definition’s so fuzzy, it’s hard to pin down a specific one to argue against). End of story. And not just in the “oh yah, I guess I’d prefer REST” sense, but in the “Web services will fail to achieve their goal, and ultimately be discarded” sense. Just because someone hasn’t done the homework necessary to properly evaluate REST, does not change this.

Extremism will live on, so long as there is right and wrong.

In the words of Henry Hazlitt (though the snippet starts slightly out-of-context);

“We Haven’t Been Good Enough”

I am going to give what is no doubt a terribly oversimplified answer to that question. In the first place, we are almost hopelessly outnumbered. Our voices are simply drowned out in the general tumult and clamor. But there is another reason. And this is hard to say, above all to an audience of this sort, which contains some of the most brilliant writers and minds in the fields of economics, of jurisprudence, of politics, not only of this age but of any age. But the hard thing must be said that, collectively, we just haven’t been good enough. We haven’t convinced the majority. Is this because the majority just won’t listen to reason? I am enough of an optimist, and I have enough faith in human nature, to believe that people will listen to reason if they are convinced that it is reason. Somewhere, there must be some missing argument, something that we haven’t seen clearly enough, or said clearly enough, or, perhaps, just not said often enough.

A minority is in a very awkward position. The individuals in it can’t afford to be just as good as the individuals in the majority. If they hope to convert the majority they have to be much better; and the smaller the minority, the better they have to be. They have to think better. They have to know more. They have to write better. They have to have better controversial manners. Above all, they have to have far more courage. And they have to be infinitely patient.

(thanks to Roger Costello for the pointer)

Just reading through a relatively recent update to the Grid’s Grid Service Specification. In there, they actually provide some (extended) WSDL that is used to access all Grid services; a generic interface, who would’ve thunk it? Some of the relevant text from that part of the spec includes;

In order to support discovery, introspection, and monitoring of Grid service instances, we introduce the concept of service data, which refers to descriptive information about a Grid service instance, including both meta-data (information about the service instance) and state data (runtime properties of the service instance). — from section 4.4

So it’s good to see them getting this important aspect right (at least to an extent – it’s still much less useful than GET/PUT/POST/etc..), but it would be nice to see them embrace the Web rather than getting distracted with what people know to be Web services, since the Web already does most of the things they’re trying to do, and many beneficial things they haven’t even thought about. I attended a BOF of theirs at WWW 2002, and they had absolutely no interest in using URIs (though I see they’re using them as Grid Service Handlers), and thought that protocol independance was a feature, not a bug. They really need a protocol guru on the team; without one, and some major changes, the Grid isn’t going anywhere.

I just made an interesting observation regarding all these orchestration, workflow, choreography Web services specs recently released. Let’s see who in the Web Services Architecture WG picks up on this …

Clemens writes some moreabout HTTP, transactions, reliability, despite his publication deadline. Go, Clemens!

FWIW, I don’t disagree that this is a commonly held view, but in my view, it’s entirely incorrect. HTTP is not a panacea, but it’s also not just a web page retrieval protocol. Some point-by-point responses;

• I said that HTTP, without resorting to things like tunneling or callbacks, doesn’t support any flavor of transactional behavior[...]. This is incorrect. HTTP supports what is sometimes referred to as a “state alignment transaction”. That is, any party in the transaction can synchronize with the state of the other party using HTTP GET. State alignment is a form of transactional style that fits very well with the Internet/Web. Obviously, just using GET isn’t sufficient for all transactional needs, even with a state alignment approach, so more work remains to be done. But to suggest that HTTP doesn’t and can’t do transactions is false.
• For additional cases where HTTP doesn’t really work (P2P in general and even non-transactional, long running operations)[...]. I use HTTP for P2P on a daily basis. My company’s HTTP routing platform is premised on the fact that HTTP is suitable for P2P, and we’ve built some really cool, useful, and scalable stuff with it. Ask KnowNow about this too. WRT long running operations, see above re state alignment; you just have to look at the problem differently.
• I can’t say that I understand what you mean by the TIP/BEEP/HTTP pictures, but the prose preceding it suggests that you didn’t understand my point that you quoted. I see reliability as an application layer issue, not a transport one. See what Jim Waldo has to say about the topic (chapter 5, if you don’t have time to read the whole thing).

Clemens responds. It’s a bit long to respond to in detail, but I will point out another big misconception about HTTP; that it is unreliable. It is as reliable as any other workable protocol can be without being brittle, because it attempts to expose what needs exposing, and hides what can reasonably be hidden. Going back to those fallacies, number one is “the network is reliable”. This should hopefully not come as a surprise to anybody, but what might is a corrolary of that fallacy (that I just devised 8-); Not only is the network not reliable, no layer that attempts to abstract that network can be reliable. “Reliability”, in the context of Internet-scale systems, is an aspect of the coordination semantics of the over-the-wire agreement, not of the quality of service of the transport of the message.