Web Things, by Mark Baker

Doug Kaye responds. It seems we did miscommunicate. I like to tweak my terminology on occasion, to try to blur distinctions for my readers that I believe are artificial, such as that between objects and resources. It came back to bite me this time it seems. I’ll be more careful in the future.

Doug writes;

I continue to believe that dynamic documents, such as those which evolve during a complex business process, are best communicated through non-REST style interfaces.

Which is weird, because I’d say that is what REST does best. A URI is just an identifier. I could use one to identify some instance of a business process, and at any point, anybody with that URI could invoke GET to retrieve a document which represented the state of the process. As the process makes progress (in any direction 8-), subsequent GETs will return different results representing the current state. I’m not sure how else to handle viewing dynamic processes, other than transferring some mobile agent pickled with its state, and then prodding the agent for the info, but I don’t think Doug’s talking about that. Hmm…

If you’re following the TAG discussion regarding the httpRange-14 issue, you’re probably aware of the two (at least I think and hope it’s just two) positions about this; either http URIs without a fragment identifier can identify anything, or they can identify “documents”, aka “information resources”, aka “cyc:ConceptualWork”s. I’m unapologetically in the “anything” camp.

As this debate has flared up every few months in some forum for the past several years, I thought a bit about some of the implications of my position, and whether there was anything there that hadn’t yet been said. I came up with a couple.

First, in general, who’s to say that any string can’t identify any thing? My name is “Mark”, and that name identifies me; not globally uniquely of course, but I don’t think anybody would claim that it wasn’t an identifier. So as an identifier, it would be really nice to be able to ask a HTTP proxy for a representation of me using that identifier, e.g.

GET Mark HTTP/1.0
Accept: image/jpeg, text/html

The only reason that isn’t possible, of course, is that HTTP accepts URIs on the request line, not arbitrary words. This is because URIs have more structure than your typical word such that a machine can extract out all the information it needs in order to retrieve a representation via late binding.

So assuming we all agree that “Mark” is an identifier for me, then we should all expect that the request above would return a representation of me. Why then, should our model of how this works be any different if I use “http://www.markbaker.ca” as the identifier for me in that request? My name is not “Mark#him”.

Second, it appears to me that adding a layer of indirection in the form of having a URI-with-no-frag identify “ConceptualWork about <subject>” rather than just having it identify the subject, removes the ability for state changes to be made. Consider my canonical “Web services are broken” example of a lightbulb; we have a URI that identifies the lightbulb, GET returns a representation of it to us, we toggle the “on/off” part of that representation, and then PUT it back to that same URI. In that example, there exists a perfectly reasonable expectation on the part of the client that PUT would change the state of the lightbulb (assuming the history of representations returned via GET was consistent with the URI identifying the bulb). Adopting the “http URIs identify cyc:ConceptualWorks” position would appear to force PUT to mean “write a new version of the ConceptualWork”, with no way to model actually changing the state of the lightbulb. Not good!

Note that this example was sort of similar to Roy’s POST/robot example, but using PUT instead of POST. I find PUT superior to POST for examples like this, because it’s easier for most people to understand what PUT does. But the principle is the same.

So to sum up, if it walks like a duck, and quacks like a duck, it’s probably not a ConceptualWork about a duck.

Sean points to a white paper he co-authored on “Service Oriented Integration”. Now, the content is almost all RESTfully delicious, but I can’t get past the terminology. It talks about the need for very generic, coarse grained interfaces (yah!), document flow, etc.., but uses the term “Service Oriented” all over the place too. I know it’s technically a very generic term, but it’s extremely commonly understood to mean application-specific interfaces. IMO, this takes away from the value of the paper, as it doesn’t provide a sufficient “jolt” to the reader proficient and/or familiar with what “Service Oriented Architectures” are, such that they’d recognize the major point the paper is trying to communicate.

But maybe it’s just me.

I was going to write more about services vs. resources here, but it’s late and I’m tired. Perhaps later this week, once I finish the DOA 2003 reviews (eight of them, ick!).

I just found this wonderfully written description, by Joseph Reagle, of the value of both pragmatic and principled approaches to group work.

Often there are debates about the means used towards common ends: are we better served by being pragmatic or principled? I think both are useful positions. For example, some individuals might choose to be uncompromising, to stand far out on the edge of the lever. In their singular position they don’t weigh much, but their extremity does increase the torque by reminding us of the principle at stake. Others might devote themselves to the process and institutions of consensus. The fulcrum itself is unwieldy and difficult to move, but if one can shift it, that too can have a profound effect on the ultimate balance.

I’ve always felt this. I’ve experienced a couple of occasions in my standards work, where a principle needed to be relaxed in order for concensus to be reached so that the work could make any progress. I’m happy to disregard principles when (and only when) I feel that the value of getting something done, however flawed, is higher than the value contributed by that principle. But, that’s quite often not the case. My stance against the current “SOA” approach to Web services, which rejects pretty much all the important principles that made the Web such a success, is an example of that.

Back in May, I was worried that my prediction that XMethods would list less than 400 available services may not come true, as 358 services were listed back then. I just checked the number now, and it was down to 342. I’m not sure why the dip – I’ll have to ask Tony – but I’m breathing a little bit easier. 8-)

I wonder, if Web services are going to be such a big thing, then surely at some point there’ll have to be millions of them around, right? If so, what do folks think it will it take to get there (other than tens of thousands of years 8-)?

Clearly Doug hasn’t been following along on the home game version of “Tech Curmudgeon”! 8-) He writes;

Mark Baker has thrown up his hands in frustration over the work of WS-Arch. “The sun will set on Web services, as it has on every other attempt to deploy object-specific interfaces on the Internet.” Object-specific, Mark?

Right, object-specific, in contrast to object-generic. That is, rather than each identifiable thing in the system (service/object/resource/whatever) having an interface specific to its offered functionality, all things have the same interface. I talk a lot about REST’s uniform interface here; that’s one example of an object-generic interface. JavaSpaces is another one.

Or perhaps I didn’t understand his question.

I’ve always considered WS-Routing to be one of the few shining stars of the WS-* spec family. Conversely, I’ve said before that I consider WS-Addressing to be perhaps the biggest waste of time yet developed. So imagine my surprise when Edwin notes this passage from Microsoft’s WSE 2.0;

One of the changes between WSE 1.0 and WSE 2.0 is the support for WS-Addressing. WS-Addressing largely replaces the capabilities of the WS-Routing specification that was supported in WSE 1.0. Instead of focusing on routing paths, WS-Addressing functionally provides a mechanism for adding To and From headers to a SOAP envelope.

WS-Routing uses URIs for endpoint and intermediary identification, whereas WS-Addressing exists because apparently URIs were considered deficient as identifiers. If you buy WS-Addressing’s premise (I don’t, surprise), this makes sense, sort of. But then you’re missing the value-add of WS-Routing and its support for SOAP intermediaries. The WSE 2.0 use of WS-Addressing defines a much less general routing infrastructure, premised upon only ever using gateways (where messages must terminate) rather than both gateways and proxies as WS-Routing supports.

While noticing one of the scaling problems with Web services (a topic worthy of its own blog entry, but I can’t muster the energy), Dave Orchard suggests that XML’s “self-describing nature” will save the day.

Producing self-descriptive documents is hard. XML has some tools that help, in particular XML namespaces, and that it’s markup. But I see those as akin to having a hammer and nail in your hand as you attempt to build a house. XML’s “self-descriptive nature”, even if you accept that “XML” includes namespaces, is only slightly better than ASCII.

I’ve been doing a lot of self-describing data investigation over the past few weeks, and the last thing I consider important is which syntax is used. What I’ve found to be most important is that identifiers be URIs, and not to use an identifier where what it resolves to is what is really needed.

I unsubscribed from ws-arch today. There comes a point where you have to throw your hands up, and realize that sometimes very smart people can be very stupid, and aren’t interested in hearing that they’re wrong. Besides, my new job is building RESTful services on an extremely large scale (international), so I no longer have a personal stake in seeing Web services succeed.

To Mike; thanks, you made it bearable. I know you tried, and you’re a good guy and a fine chair for doing so.

To working group members; it would serve you really well to understand software architecture better than you do, and to understand why constraints aren’t necessarily constraints on function, only form.

The sun will set on Web services, as it has on every other attempt to deploy object-specific interfaces on the Internet. I was hoping to be the guy who’d help people understand why this would happen, and in the process, save the industry from wasting a whole lot of time and money. But I suppose there’s no substitution for learning some lessons the hard way.

I’ve been meaning to be more involved in this, but it’s been moving too fast, and I’ve been too busy with other things (like a job).

A comment by Tim Bray in today’s TAG meeting minutes, however, prompted me to check back;

over in son-of-RSS-land, we’re converging on using POST for entry creation/update/deletion for reasons that seem good

My concern with that is that the resulting API would not be RESTful, and I thought that the objective was that it should be (as the name RestEchoApi suggests!). It isn’t RESTful, because in the context of HTTP, tunneling methods over POST – even uniform ones – reduces visibility.

I added my two cents.