Web Things, by Mark Baker

Simon Fell says that he has trouble understanding some of my arguments, in particular this one where I attempt to outline the value of pipe-and-filter style composition over a choreographed solution. Let me elaborate here then.

It’s long been recognized that composition of components is simpler and more tractable when those components share an interface, if only because you can reuse glue code. For example, the code written to late-bind the Unix commands “ls” and “more” into “ls | more”, is split between the stdout-using code of “ls”, the stdin-using code of “more”, and the binding code in the shell that processes “|”. All of that code is reusable in more contexts than piping “ls” into “more”.

My examples were meant to show the strong similarities between Unix style composition, and REST style composition. REST, by itself, supports two styles that I’m familiar with, which I described there; composition-by-URI, and intermediary routing. The latter is more powerful and flexible, but the former easier to use, though at the cost of not being standardized (not that it should …).

From what I can tell, the Web services answer for composition lies with choreography (and some in that thread appear to agree with that). I believe this approach will ultimately fail, and that routing (ala WS-Routing, PEP, Idokorro, KnowNow) will prevail.

James Strachan asks that if the method doesn’t go in the SOAP envelope, could it go in the URI or an HTTP header? My answer would be “No”, that in order to gain the benefits of REST, the only method you need should be the one in the HTTP request line, such as GET/PUT/POST. That’s not to say more methods can’t be defined, only that they should all have uniform semantics, and that when using HTTP, they should be HTTP methods.

Does that explain why HTTP is an application protocol, and not a transport protocol?

More tail-chasing going on over at the W3C with the chartering of the Web Services Choreography WG. I’m really disappointed that Tim didn’t take this opportunity to speak his mind about the mistakes being made with Web services, especially considering that this working group exists to replace the hypermedia application model, which is pretty darned fundamental to Web architecture.

I guess he knows what he’s doing though. Perhaps he feels he can contain Web services, and prevent them from preventing him from leading the Web to its full potential. I did think that the initial move to accept them into the W3C was an excellent one, as there, they may actually be fixed enough to earn the right to call themselves Web services. Unfortunately, nobody seems to be officially assigned to the task to doing just that, though Hugo and David try to keep things in check, what most people know to be Web services (i.e. putting the method name in the SOAP envelope) is a fundamentally broken style for the Internet, which is a big issue for them to tackle, especially given the mostly neutral positions they’re expected to hold as team contacts (not officially, but in practice it’s hard for them to hold strong opinions). That’s why I’ve been doing it.

Sam Ruby implements the RSS Trackback module in his RSS 2.0 feed. It’s implemented by simply including a “trackback:ping” qualified URI in the item. For the item that corresponded to his announcement of support, the URI is;

http://www.intertwingly.net/blog/1105.tb

So being the Web-head that I am, I invoked GET on it. Here’s what I saw;

<?xml version="1.0" ? >
<response>
<error>1</error>
<message<excerpt not found</message>
/<response>

I note that Paul, Ben, and Mena had written about what could be returned, which is bang on from my POV, though you could also include the number of received pings in there, which could be useful, and make a nice link from the human-readable blog.

Just thinking out loud; I’m not trying to put more work on Sam’s plate 8-).

A nice surprise turned up in my IETF mailbox this yesterday, Applying WebDAV to Network Configuration Management Problems.

This memo examines the potential of using WWW Distributed Authoring and Versioning (WebDAV) technologies to address the problems of network configuration management. It reviews requirements and issues that have been identified in IETF network configuration management and operator requirements discussions, matching these requirements and issues with various WebDAV facilities. It concludes by identifying areas for further exploration.

Bravo. We need more of this kind of reuse-friendly work.

Which reminds me … I forgot to mention that an Internet Draft that I wrote with Dan Connolly on a related topic (reuse, in the context of registries) was published too.

I awoke this morning to a dead Wifi network in my house. Oh joy. Close to three years of pure bliss of 802.11b in the whole house, then nothing. A quick investigation turned up an almost identical report explaining the state of my base station. It looks like it’s totally dead. In the mean time, I’m now shackled to my basement PC until this gets fixed. At least I’ve got my new monitor to keep me comfy there.

Arthur C. Clarke’s third law says;

Any sufficiently advanced technology is indistinguishable from magic

After a busy several days on www-ws-arch I’ve come up with my own version;

Any sufficiently advanced technology is likely to be marginalized

I came up with it to explain the different binding approaches taken by the Web and Web services.

A priori knowledge plus Ex post facto knowledge = Constant

Any suggestions for a name for this principle?

Sean McGrath points out that some folks (himself included) are making predictions for Web services in 2003. It’s surely an oversight that I wasn’t asked for my predictions 8-), so here they are;

• Web services will continue to struggle on the Internet. XMethods will list only 400 available-over-the-Internet services by the end of the year.
• The WSA WG will have their architecture document reviewed by the TAG and the Director. One or both of the two will reject it as being incompatible with Web architecture. Much nastiness will ensue.

Sean McGrath calls for a “workable definition” of a Web service in order to bring integration complexity down to O(n) from O(N^2).

While a definition would be a good start, more importantly we need a common abstraction. This drives integration complexity down because once you’ve integrated with one service, you’ve (ideally, and not that uncommonly) integrated with them all.

Take for example, a blog aggregator. If everybody had their own interface to their blog, aggregation would be an O(N^2) task. But luckily they don’t, they all make their RSS available over HTTP GET, a very useful common abstraction. That, plus that RSS (all four versions 8-) is a common format, provides for O(N) integration complexity.

The Web provides one common abstraction that I talk about a lot; the uniform interface. There are others (though none so general, I believe), but Web services, via WSDL, are all about providing custom interfaces. As long as use of WSDL in this manner continues, Web services will, like Sean says, amount to “one big damp squib” (which doesn’t sound like a good thing 8-).