Web Things, by Mark Baker

When the Web Services Architecture WG closed down, I took the opportunity to ask working group members what their reasons were for not using REST as a base for Web services. I continue to hear, on an almost daily basis, about how the Web is for humans, so that’s what I expected to hear. Instead, to my surprise and elation, I heard comments such as this from Roger Cutler;

Although I have not put the time and effort into studying it enough to be very sure, what I have seen of the REST-like solutions you have proposed or described to problems addressed by Web services indicates to me that it COULD have been done that way and that it would have worked. In fact, it’s even possible that it would have worked better and that it would have been better had it been done that way. I don’t really know that this is the case, but I think it’s possible it might be. I also think it’s utterly irrelevant. What’s done is done, and the world ain’t goin that way. In hindsight there are many, many places in the way all sorts of things have developed in the world that might have been done better or more directly. The progress of human affairs is imperfect at best. I personally participate in those imperfections.

A couple of other people responded, basically agreeing with Roger.

This is an important milestone, I’d say. It seems to signify the end of the “REST Wars”, as some Web services folks now accept that there are RESTful solutions to application-to-application integration over the Internet. Stage one is complete.

Stage two – which I’ve been arguing alongside stage one, but can now apparently focus upon more intently – is about software architecture; that unless your architecture has the properties your environment requires, you will fail. Even pervasive agreement on an architecture lacking in those properties is an insufficient condition for success.

Onward to stage two! Let’s hope this one doesn’t take another four years of effort (that message was my first message critiquing Web services, AFAICT).

Savas responds, noting he and his co-authors had previously patched that portion of their paper. Great. Here it is;

There have been proposals for naming and uniformly providing access to resources, such as the REpresentational State Transfer (REST) [24] model. However, since REST depends on HTTP (or more accurately a protocol with HTTP-like semantics) it is protocol specific and hence unsuitable for heterogeneous systems like the Grid. It also requires a particular interface to be used with the exposed resource, hence coupling identity and interface. In practical terms, this means that HTTP proxies must be placed in front of non-HTTP aware resources (e.g. FTP).

My first comment is that it appears contradictory; the last sentence talks about how other protocols can be supported, yet the previous paragraph still claims it’s protocol specific.

Another comment concerns the last sentence of the first paragraph; I think Savas probably got that from something I said to him, but I should elaborate. Identity and interface are coupled only in the sense that there’s a default association of URI scheme to protocol. But that association is not to the exclusion of other protocols. Consider an ftp URI; alone in the wild, that URI maps to, basically, the FTP RETR method. But one can use that same identifier in the context of any system whose interaction semantics can subsume those of FTP, for example, HTTP. I wish there were another example of systems that it could have been subsumed by, but I can’t think of one. And FWIW, what’s special about HTTP here is that, for *all* URIs, HTTP is an answer to the question “Name a protocol, other than the one suggested by the URI scheme, which can be used to interact with the resource identified by this URI”. That’s why HTTP is so special (and another explanation for why protocol independence is such a harmful concept).

Good stuff though. I’m really very encouraged by this work, and WS-RF too, as from my POV, both seem to be getting closer to the sweet spot of the Web as large scale integration solutions.

Bill de h&#211ra on Web services;

In early 2004, the Achilles heel of web services is the complexity resulting from the sheer volume and lack of coherence in the web services specs and a lack of architectural guidance from the folks generating them

Yup, big +1

And now that the Web Service Architecture WG is closed, I wonder where this guidance will come from? That’s why I’m honestly disappointed at its closing, despite voting against its chartering as a W3C AC rep a couple of years ago.

A really bizarre article on IEEE Spectrum. I say bizarre, because it totally nails the problem (linking databases), yet totally flubs the solution (Web services).

If you want to open up your databases and link them together, look no further than the Semantic Web.

Update; yes, I know it’s a pro-Semantic-Web article, I’m just pointing out the misconceptions about Web services. They are not about publishing data. That’s what the Web is for. The article even claims that HTTP was designed for HTML, which is totally false.

Via Savas (subscribed!), I’m following a lot of the discussion regarding the recent Grid/Web-services “unification” specs, WSRF. Good stuff! These folks are even closer to having their Web gestalt moment I believe, as they’re now talking about “stateful resources” (now where have I heard of those before?) in the context of integrating two different systems, the Grid and Web services. Rock on! I think I’ll sign up to a mailing list or two.

While following those links, I ran across a proposal by Savas and his group called WS-GAF, a sort of accidental precursor to parts of WSRF. It mentioned REST;

There have been proposals for naming and uniformly providing access to resources, like the REpresentational State Transfer (REST) [2] model. However, since REST depends on HTTP it is protocol specific and hence unsuitable for heterogeneous systems like the Grid.

First, I just want to say that I think it’s wonderful that REST was even mentioned in the context of the Grid. Most folks think it’s still just for humans and browsers and HTML. Very refreshing. Now for the bad news (come on, you knew it was coming … 8-). REST does not depend on HTTP at all. It is an architectural style, and therefore prescribes no specific implementation, it just describes the constraints that one uses when designing a RESTful system. You could run out and build one that didn’t use any existing technology, if you wanted to.

Savas might be interested in a response of mine to Werner Vogels regarding his Web services are not distributed objects paper.

WS-GAF still uses URIs, which is great. Here’s an example of one;

urn:dais:dataset:b4136aa4-2d11-42bd-aa61-8e8aa5223211

This is wonderful, in a sense. It’s the first time I’ve seen that we’ve narrowed the whole SOA/REST/Web issue down to an issue of Web architecture, in particular, httpRange-14 (well, you have to squint a little to see why it’s really that issue – it could have been called the “uriRange” issue, i.e. what can a URI identify?).

So my claim is that WS-GAF would be far better off to identify its resources using http URIs, for the same reason that “info” scheme users would.

Lots of distributed object, SOA, Web, Web services talk going on recently …

Dare Obasanjo on Web/SOA;

What Don and the folks on the Indigo team are trying to do is apply the lessons learned from the Web solving problems traditionally tackled by distributed object systems.

I know they’re trying to do that, but what they’ve (and most nearly everybody else) have missed, is that the Web is already a distributed object system; it has its own way of addressing most of the problems that previous attempts at distributed object infrastructures attempted to solve. For the things it doesn’t address, Web extensions like the Semantic Web and ARREST cover them … and then some.

James Robertson on HTTP, documents and coupling;

Here’s my point though. It’s magic thinking to say that you have looser coupling simply because you use Http transport and XML documents. It’s a fantasy. Why do I say that? Well, let’s posit a blog server that accepts XmlRpc formatted posts. There you go – http transport, xml documents.

HTTP isn’t a transport protocol. It’s not intended to send RPC messages, it’s intended to send real documents like images and resumes and letters and purchase orders and … anything that is serialized state. If you use it that way, then there is magic there, because it gets data into the hands of somebody else’s application code, rather than into the hands of some infrastructure code.

It’s actually no different than CORBA – except that maybe it’s slower. Either way, I have a server listening on a port, expecting data in a given form, and able to perform a constrained set of actions if I send it the right requests – and ready to send back errors if I don’t.

CORBA only tells you that objects have interfaces. HTTP tells you what that interface is.

More later…

Chris Ferris writes, regarding BEEP and HTTP;

The BEEP protocol offers much richer message exchange patterns than does HTTP, enabling the likes of publish/subscribe, one request/N responses, etc. without having to resort to hacks.

I’m not a fan of BEEP, primarily because I see little value in standardizing at that layer (OSI layers 5 and 6) without standardizing up higher with an application protocol, because layer 7 is where interop happens on the Internet.

But I have to take issue with the “hacks” jab. He and I went back and forth on at least one HTTP extension in the early days of the Web Services Architecture WG; the MONITOR method. Is that a hack? Is mod-pubsub a hack? (well, parts sure are, but the bulk of it? 8-)

I suppose if you have the luxury of working in a greenfield environment with little in the way of architectural constraints (e.g. BEEP), then you can pretty much do what you want, and perhaps you’ll end up with something quite elegant. But doing the same thing with an existing architecture is much harder because you have more constraints you have to work within. That doesn’t make them hacks.

Via service-orientated-architecture, a good article, with a great point;

Having a JavaSpaces foundation makes it possible to tackle the modernization of an enterprise application portfolio in a distributed fashion. It becomes possible to modernize front ends without petrifying back ends by agreeing on an abstract middle layer to which all the actual IT assets can connect without concern for what’s on the other side. It lets each center of responsibility make its own decisions about the relative urgency of various goals so that those who have budget accountability also get to decide what will be done when-an essential part of any rational goal-setting process.

Very well said, especially the “abstract middle layer” bit. Of course, there’s nothing special about JavaSpaces in this regard; any interface constrained around an abstraction, be it a space, a resource, or an email inbox, will buy you these same benefits.

So if similar architectural styles to JavaSpaces are the evolution of Web services, and Web services are the evolution of the Web, then why does JavaSpaces look so much like the Web?

Yikes, I awoke this morning to about 100 new emails, 42 of which were this beast. And those were just the ones that evaded the spam filter. It also constituted about a third of the 200 or so spams caught by my filters.

I’ve never been hit so hard.

Via Ted, Stefano’s trying to trace the history of the inversion-of-control pattern (well, I think it’s a pattern at least 8-) used in frameworks.

I used it in my own work in ’94/95 when I first got into C++, and shortly thereafter with Java in the summer of ’95. But it was perhaps late ’95 (confirmed; it was published in Sept ’95), when I first saw it described and referred to as the “Hollywood Principle”. That description was in the famed “blue book”; Bob Orfali, Dan Harkey, and Jeri Edwards’ The Essential Distributed Objects Survival Guide.