Web Things, by Mark Baker

I was just reading over an article that gives a very high level overview of GXA, which, like so many others, makes the fundamental mistake of talking about HTTP as a “transport protocol”. Of course, one only need look at the HTTP spec to see that it’s not, it’s a transfer protocol, which is a very different beast; a coordination language dealing in state.

But after writing about coordination languages last night, something occurred to me; that the more general a transfer protocol, the easier it is to mistake it for a transport protocol. HTTP, effectively, has only two methods; GET and POST, and they are commonly confused with the semantics of send() and recv(). Other transfer protocols, like SMTP, or IM protocols, are also often confused with transport protocols, for the same reason.

Coordination languages come in very general and very specific flavours. WS-Transaction is very specific, for example, as it deals only in “transactions”; any task which can be modelled as a transaction, can be accomplished with WS-Transaction.

An example of a very general coordination language, would be tuple space based systems such as Linda or Javaspaces. These are general because they both deal in an abstraction known as a “space”. A space is a more general abstraction than a “transaction”, because more things can be modelled as spaces. But not every thing. For example, modelling a lightbulb as a space leaves one no way, without additional agreement, to check if the bulb is on or off.

Of all the coordination languages that exist though, I suggest that there is one that is the most general, and it is REST’s “uniform interface”; it deals in “resources”, which includes every thing.

Edwin points to some BPEL presentations. I read Satish’s (PPT), and saw the term “coordination language” mentioned in the context of Web services for the very first time. It’s about time, as the Internet’s application layer is populated by a variety of coordination languages, otherwise known as application protocols.

Werner Vogels writes;

The keynote was by Tim Berners-Lee who did a truly awful job in trying to make a connection between web services and the semantic web.

Yup, absolutely agreed. I read over his slides last night, and, like Werner says, was waiting for some new connection to be presented that I also hadn’t considered. But nope. Very disappointing.

I’m pretty sure I know what Tim was trying to do though. He was trying to “embrace and extend” Web services by convincing people that they needed the Semantic Web for data integration, with the expectation that once it is in use, that the need for application-specific interfaces would melt away.

I’m confident that won’t work. For one, if there’s anything that’s held in more contempt by Web services proponents than the Web for app-to-app integration, it’s the Semantic Web. They see it as an academic exercise, and irrelevant to the “needs of business”. Of course that’s wrong, but the belief that it’s true is pervasive in this community. It seems that “the needs of business” has become synonymous with architectural styles that resemble CORBA and DCOM. It is that which needs to be refuted.

It’ll be interesting to see if Tim will keep up this tact when facing the architectural problems with Web services in response to my issue to the TAG.

Yesterday, I proposed a new issue to the TAG regarding what I consider factual errors in the recently published draft of the Web Services Architecture document concerning the architectural property of visibility. You can read the text for yourself, but I thought I’d explain why I raised this issue and not the more general and abundantly obvious “Web Services are incompatible with Web architecture” one.

My principle motivation was that I wanted a very well defined, bite-size topic for the TAG to chew on; one that could be resolved in short order, but that still had “architectural impact” and relevance to Web architecture. In addition, I wanted to pick a topic that the WSA WG had already agreed was important, but believed they had it covered. My end goal is that having this issue resolved in my favour will be enough of a boot-to-the-head to the WG, that they may see where they’ve erred, especially as the resolution will presumably drive home the critical point that application protocols define application interfaces.

It’s a bit of a risk; perhaps the WG members won’t see it that way and I’ll have wasted an opportunity. But I figure that all I need to do is to convince one staunch Web services proponent, and then the house of cards will topple. Plus, it’s unlikely that discussion on this topic will be able to avoid the more general problems with Web services, so there’s an opportunity for additional issues to be raised by others.

Smart move, or missed opportunity? Time will tell.

My inbox collected a few, erm, “colorful” emails this past weekend. It seems that more than a few people have had enough of my pro Web architecture position.

I’m confident of my earlier predictions, but perhaps I underestimated how nasty this is going to get. If these messages are any indication, this will be indistinguishable from a war.

Place your bets!

A very nice piece from Tim on how Web services should look; RESTful.

Dave, Sam, and Don have all responded.

First, to Tim, right on man. It’s about time too. For quite a while, he’s seemed to be on the fence, but this seems to make it quite clear where he stands, and hopefully where he’ll be voting on Decision Day. Perhaps with a name as well respected as his firmly in the REST camp, more people will take notice.

To Sam, a couple of points. First, safety != idempotency. Safety means messages don’t change state (roughly). Idempotency means multiple messages have the same effect as one. All safe operations are idempotent, but not all idempotent operations are safe. For example, PUT is idempotent but not safe. In addition, having the response change for a GET, even in a very short period of time, is perfectly RESTful. What isn’t RESTful is if the result changes because GET was invoked (and the owner cares about the change).

Also, the “take three parameters” analogue misses a major point I believe. In the POST/SOAP/XML-RPC case, sure you get the same info back, but you have no way to refer to that info, or pass references around to other parties. When you marshal data into a http URI, you are creating a token which has associated with it a publicly specified method for dereferencing. That is a vast improvement over the one-time use-and-consume approach of POST for retrievals.

Sam writes;

A distributed system across trust boundaries is where I believe we are collectively heading.

Hey, wait a sec’, we’re already there; the Web and email cross trust boundaries. We even know why that worked too, so we have no excuse when mistakes are made.

Obviously, Sean just doesn’t get it. You’ve got to be protocol independent, so that you can invent a new application protocol on top (i.e. DocSOAP) upon which you are then allowed to become dependent. Silly wabbit.

Show me a WSDL document, and I’ll show you a poorly designed application protocol.

Sean asks for pub/sub on the Web. I wonder if he’s familiar with KnowNow, and in particular their open source project, mod_pubsub? They’ve got some nifty demo apps you can play with too.

We implemented something similar at Idokorro too, but for mobile clients which had our own browser installed (with its own embedded web server).