Web Things, by Mark Baker

James Strachan sums it all up when he says;

[…]Whatever happens in this whole web services thing, I do think alot of good has come from it already. Its forced people to think alot about distributed systems and why the web works and scales – there’s a lot of great lessons there. Its also brought together lots of diverse communities from the web side of things, from MOM folks and distributed objects folks. If nothing else its made us look again at distributed object technologies like DCOM, CORBA, EJB and ask lots of questions – I think its also taught us what a leaky abstraction the traditional view of distributed objects are.

This is exactly my view. Once this is all resolved – and I hope for the industry’s sake that it is soon – a lot more people will be appreciative of the extent of the gift that TimBL gave to the world, and the principled design that Roy laid out for us.

What doesn’t kill you, makes you stronger.

And FWIW, I’ve maintained my “distobj” email address for a reason; the Web is a distributed object infrastructure, with the critical innovation that all objects implement the same interface (have I said that enough yet? 8-).

I’m officially unemployed now. I’m not quite sure what I’ll be doing next, but I’ve already been contacted about doing some consulting work in the enterprise Web services space. Consulting would be “ok”, but it would be nice to have the relative comfort of a “9 to 5” job for a little while after a year of doing my own thing. Plus I think I would have a bigger impact if I was with an established company with customers to satisfy.

So if you’re interested in the services of a large scale distributed systems expert who knows why Web services will fail, and how to fix them, drop me a line.

Jon discusses the pros and cons of uniform versus specific interfaces. This really is, as Dan Connolly described, a “fascinating tension”. So Jon’s in good company. 8-)

I agree with the gist – that there are pros and cons to each approach – but I disagree with the conclusion. Towards the end of the blog, Jon writes;

It’s a great idea to push the abstraction of the core primitives above the level of SELECT/CUT/PASTE. But there’s little to be gained by pretending that a table of contents is a pivot table.

If you’ve already deployed a network interface which is capable of accessing and manipulating pivot tables, then there is an enormous amount to be gained from being able to reuse this interface to access and manipulate table of contents, table of figures, or even dining room tables. Deploying new interfaces on the Internet is extremely difficult, expensive, and time consuming. The SELECT/CUT/PASTE analogy, while illustrative, doesn’t reflect the nuances of a network interface, which must work between multiple trust domains, not within just one.

WRT “ANALYZE” and “IMPROVE”, both of those “actions” can be accomplished without introducing new methods on the interface. For example, “ANALYZE” is a safe action, so could be handled as piping your content through an intermediary via a GET invocation, where it “analyzed” the content and returned the results (perhaps using annotation). “IMPROVE”, as I understand it, could be implemented similarly, but using WebDAV‘s COPY method, or maybe just PUT or POST; it depends how it’s used. Either way though, the intermediary would do the “improving”.

P.S. I like to use the “drag and drop” desktop metaphor as a comparison to REST’s uniform interface; GET as “double-click” (except for application-invocation, which isn’t technically part of drag-and-drop), POST as drag-and-drop, PUT as “file->save”, and DELETE as delete. This analogy breaks down with the drag-to-trash-can action, but it holds for the most part because drag-and-drop was designed as an interface for “all desktop objects” which is pretty similar to “all resources”.

Jon follows up his Groove/REST blog by quoting Paul and I and concluding that we are actually saying the same thing. This is a really important point, so let me emphasize it here. As I wrote privately to Jon;

If you choose your verbs such that each can be used on every identifiable thing, then you have no addressing problem.

The moment your interface includes a method which is not uniform to all things, then you lose something because some aspect of identification is removed from the identifier, and moved to the method. For example, see Dan Connolly’s report on the problems with WebDAV’s PROPFIND method, which can only be invoked on WebDAV properties. On the Web this is considered a major faux pas, but it’s commonplace – arguably a defining feature – of and with Web services.

Also, this is related to my post on generalization of application interfaces.

Jon Udell writes that Groove has a REST interface, which peaked my interest. We’re discussing it over on rest-discuss.

I’m very encouraged to hear about REST being considered a cool and useful thing, and thank Jon for pushing that position. But (you knew this was coming, didn’t you? 8-) it doesn’t sound like Groove has it quite right. The bit of Jon’s article that suggested this to me was this;

It’s all organized as a web of linked XML documents controlled by a handful of verbs such as Create, Read, Update, and Delete.

It is true that a pre-defined set of small methods will help the system immensely, because coordination costs are lowered, and visibility is increased to firewall administrators (at least when the specification of its semantics are specified in the open, or just standardized). But not every set of fixed methods means you have a RESTful interface. As I described on rest-discuss, the uniform interface constraint also has something to say about which methods you use. Specifically, it says that any method you use must be usable on all resources/objects/services/whatever. Like GET, PUT, POST, DELETE, LOCK, MOVE, COPY, etc..

It doesn’t sound like this would be that big a change for Groove if they’ve already got a CRUD interface, but the benefit is that you get all of HTTP’s other features and deployed support (e.g. Akamai) for free, plus any future extensions. RFC 2616 isn’t 420K in size for nothing, and you’re not going to ever be able to adequately replace it with a 5K WSDL file.

So this is quite encouraging, but let’s try to nip the “REST interface = any limited set of methods” misconception in the bud before it gets too wide spread.

I just realized that the best way to grab the WSDL of a service is probably via HTTP OPTIONS rather than HTTP GET. OPTIONS was designed to return information which describes the interface to a service. From RFC 2616;

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

I mentioned this on www-ws-arch.

Dave made the following suggestion for a SOAP definition;

It’s a simple way to call procedures running on other machines, on other OSes, written in other languages, using different economic systems, without being forced to pay a tax to Microsoft, IBM, Apple, Sun or the W3C.

SOAP isn’t that at all. That’s XML-RPC. Dave’s a bright guy who writes great software, but when it comes to distributed systems, there’s a lot he doesn’t understand.

The SOAP 1.2 spec defines SOAP as;

SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.

Which is a pretty decent definition, though not very detailed as to how one actually might use it. For a better definition, I look to SOAP’s brethren, PEP. It’s defined as;

The Protocol Extension Protocol (PEP) is an extension mechanism designed to accommodate dynamic extension of HTTP applications by software components; and to address the tension between private agreement and public specification.

Of course, SOAP isn’t tied to HTTP, but PEP didn’t really need to be either. It could also be patched to be an extension protocol for non-HTTP protocols, as SOAP 1.1 was “patched” in the form of SOAP 1.2.

Please, if SOAP has any chance of success, let’s try to distance it from RPC.

A couple of recent blogs and messages I’ve seen prompted me to write this. They both suggest that a “SOAP message” is necessarily a “message”. I disagree.

When bound to an application protocol, a SOAP message/envelope is not a message because it doesn’t contain the necessary information with which to understand what it means. For example, a SOAP envelope which included a HR-XML resume is not a message, because it doesn’t say what is to be done with the resume; is it to be forwarded on to somebody else? Submitted as part of a job application? Meant to update an existing resume? This is where the envelope of the underlying protocol, such as HTTP comes in; the HTTP request line (method, URI, version), headers, and the body which includes the SOAP envelope, forms the entire message.

If HTTP were a transport protocol, then a SOAP envelope/message sent over HTTP would always be a message. But it isn’t, it’s an application protocol. And please don’t think this is nitpicking. Far from it, I believe it’s the single biggest misunderstanding that has lead us to where we are at with Web services (i.e. a mess). If people knew what an application protocol was, I think many more (not all, of course) would have thought twice about proceeding with Web services.

Peter Drayton writes that some folks have had “RESTian awakenings” as a result of his presentation, which is just awesome. While reading up on one of his references though, I found this in Alexis Smirnov’s blog which suggests that at least some people still have a ways to go;

After his talk, Peter, Tim and Sam talked about a need to get a WSDL from a SOAP URI.

My response to that is, no, there is no need for WSDL. The fundamental advancement of the Web over previous distributed object systems is that it doesn’t need an interface language because all components expose a uniform interface.

An analogy; if you’re a Java programmer, think of it as working with all your objects after they’ve been downcast to java.lang.Object. Obviously java.lang.Object will only define methods which are common to all objects, so you wouldn’t expect it to have a method such as “buyBook” because not all objects are books. This is what REST’s uniform interface constraint is all about.

Peter Drayton posted the slides (PPT) from a presentation he gave at the WS DevCon. It’s very well done. Too bad I couldn’t have been there to hear it presented.