I was blown away today when I read Graham Glass’ blog to learn that Rocky Stewart passed away this past October. Rocky was a brilliant, out-spoken technologist and educator who I had the pleasure of interacting with on many occasions in the mid/late 90s, on and off the Distributed Objects mailing list.
If there’s any consolation to be taken from this loss, I suppose it would be that he died flying his plane, which was his absolute passion. My condolences to his family.
Hmm, somehow I’m just not too excited about things this year. Perhaps this has something to do with me making the most intriguing prediction – the inevitable death of Web services on the Internet – three years ahead, two years ago.
But first, let’s see how I did with last years predictions…
As alluded to above, I said that Web services would continue to struggle for adoption on the Internet, and lo and behold, that’s the case. Ho hum. +1
I also claimed that another high profile public Web service would be released. I can’t think of any really high profile announcements this past year except for eBay I guess, but theirs seems SOAP-only, and isn’t public. Bloglines announced their services, but AFAICT, they’re REST-inspired only with no SOA side. So I guess I flubbed that one.
Ok, so this year, hmmm… As I see it, things have really got to start hitting the fan in the SOA space. To that end, I make the following two predictions;
I did the little I could today, to help with the cleanup from the horrific Indian Ocean tsunami; I gave to Oxfam Canada. Please consider doing the same.
I just discovered this article by David, apparently reprinted from an old weblog entry that I must have missed while at XML 2004. While I think I’ve said my piece on the topic of distributed objects vs. services, I wanted to respond to a couple of points in the article …
First, in the “State” section, Dave seems to make the mistake of confusing the different types of state (or at least the different locations of state). He says “Web resources that have a URI that are stateless and work with HTTP GET”, which is clearly not the case, since any resource that answers a GET request answers it with a representation of their state. When you hear “stateless” in the context of the Web architecture, it’s usually in reference to the protocol, not the resource … though you can, of course, have stateless resources if you want to.
I’m also not sure where he’s going with “on the Web” bit. It’s a cute phrase, but doesn’t seem to hold a lot of technical value.
But the next three paragraphs seem to mix the different types of state up willy-nilly such that you can’t really make sense of it. The major theme does seem to be about services with state, yet Dave makes reference to conversational/application state mechanisms such as cookies. Perhaps I’m missing something.
Next, in “Network knowledge”, he adds;
Effectively, Web services is remote method invokes but with knowledge of the remoteness.
I won’t disagree with that, but what the heck happened to document orientation?! That was the single most significant architectural advancement upon RPC that I’d seen come out of the Web services space since it began (at least from a service POV – clients were still as tightly coupled to the services they used as with RPC).
In response to an issue I proposed in the WSA WG, this;
can we avoid going down the standard “mark baker” issues here?
Ouch! That hurt. But sure, you can ignore them. You do so at your peril, but feel free.
You just might want to keep in mind how previous attempts at doing that have (not) worked out.
And this is the ur-message of Flickr use at ITP – this is what web services looks like when it’s not “Web Services.” No SOAP, no UDDI, no BPML4WS, just good old REST-alicious modeling of resources, and an adopting population that wants to get things done. This is an easier and more labile version of web services than anything being hawked by Big Iron or (Big Binary) vendors.
An interesting post from Dave. A few comments…
I’ve been saying for a while now that I think it’s a shame that SOAP 1.2 didn’t define a general SOAP to HTTP binding that used HTTP as a transfer protocol, for the previous 2 reasons.
It does, Dave. The default binding is a transfer binding; I made sure of that. I think you’re confusing how people use it with how it’s defined. Web services proponents generally think that a SOAP envelope is a SOAP message, yet that interpretation is not licensed anywhere in the spec, and is even explicitly rejected in the HTTP binding where the state transition table clearly shows HTTP response codes affecting SOAP message semantics. It’s also alluded to in the glossary where the definition of the two terms differ (you think this was accidental? Hah! 8-).
I would love it if there was a reasonable way to bridge the SOAP/WS-Addressing world and the HTTP Transfer protocol world, but I just don’t see that each side really want the features of the other side. The SOAP/WSA folks want the SOAP processing model for Asynch, and don’t care about the underlying protocol. The Web folks want their constrained verbs and URIs and don’t care about SOAP processing model.
Avert ye eyes! False dichotomy alert!! You can get the SOAP processing model, and HTTP as transfer protocol (including asynch, which HTTP handles just fine despite insistance from many that it doesn’t) simply by using SOAP in the manner prescribed in the SOAP 1.2 spec and default HTTP binding. In order to do so though, you need to give up on the idea of a new (non-URI) identifier syntax. This is really not a big deal!. We are, after all, primarily talking about syntactical differences here. What EPRs are trying to do is comparable to inventing a new alphabet for the english language; perhaps there are benefits, but I think the phoenician alphabet has a, ahem, rather large and insurmountable head start in deployment, making those benefits – if they exist at all – completely inconsequential.
Dave then makes a really interesting statement of the “protocol independent” variety;
Here’s a test case: Would the Atom protocol switch to using WS-Addressing and then use the HTTP as Transport binding(s) and HTTP as Transfer binding? Seems to me not likely. The Atom folks that want to use HTTP as Transfer have baked the verbs into their protocol, and they won’t want to switch away from being HTTP-centric. And same as I don’t see the SOAP centric folks wanting to “pollute” their operations and bindings with HTTP-isms.
Emphasis on “baked the verbs into their protocol”. Seriously – no matter how you slice it you’re always baking verbs into a “protocol”, because an application developer has to know what verbs they’re using. The problem as I see it, again, is one of nomenclature; that Web services proponents have a very narrow RPC-inspired definition of “protocol” (transport), and their mental models built around this definition simply can’t fully absorb the implications of the broader definition used in the IETF and W3C (transfer). They simply can’t conceive of something called a “protocol” playing such an enormously significant role in a distributed system, yet this is precisely how all existing Internet scale systems are built, and precisely why Web services proponents haven’t yet realized that the Web is what they’ve been trying to build, at least since the quest for “document oriented” services began in 2001/2002.
One might also look at Dave’s statements and ask themselves, well, if they’re going to be dependent on a protocol, then it might as well be the most successful one ever developed rather than one which has struggled for deployment anywhere except behind the firewall. And somebody please remind me; why is it desirable to be independent of a transfer protocol, but dependent on SOAP the protocol?