WS-Transfer, WAKA and the Web

Wednesday, 15 March 2006

Microsoft and friends (of the keep your enemy closer variety, I suspect) have submitted WS-Transfer to the W3C. I found the Team comment interesting; e.g.,

WS-Transfer can therefore be seen as an underlying protocol-independent version of HTTP, i.e. bringing the capabilities and properties of the Web and HTTP in contexts where HTTP is not used. The use of WS-Transfer is not limited to non-HTTP transports, and can also be used when HTTP is used as a communication tunnel.

As usual, the Team has balanced the need to be polite to Members with healthy (if veiled) scepticism.

“Protocol-independent version” implies fidelity to the original, something that I don’t think WS-Transfer has, and that’s the problem with WS-Transfer; the devil is in the details. From 50,000 feet, it “can be seen”, but as soon as you try to do a one-to-one mapping of particular features and usage patterns, you discover it’s not a perfect fit, or even a good one.

Case in point: caching. HTTP has a pretty well-developed caching model; will that work in SOAP? Nope, unless you want to deploy a HTTP-on-SOAP-on-* caching infrastructure. Or media types — do you really think that Web services applications will do dispatch on a SOAP header containing an Internet media type, just because they’re using Transfer?

“Bringing the capabilities and properties of the Web and HTTP in context where HTTP is not used.” Think about that statement for a second; while it’s theoretically possible, why would you deploy a HTTP-on-top-of-SOAP protocol when you could just deploy HTTP? What value does SOAP bring to that picture? For that matter, what does SOAP run on top of in the real world, besides HTTP?

A good chunk of the value in HTTP (and the Web) is in the facts that a) it’s not owned by any one company, and b) there’s wide deployment and proven interoperability. Transfer fails on both of these counts.

WS-Transfer isn’t a version of HTTP, it’s a competitor. It’s a diversion that keeps developers — in case they actually get interested in REST — on the SOAP ranch.

What about WAKA?

Interestingly, there’s another effort to supplant HTTP on; Roy Fielding is (still) working on WAKA [ppt]. It’s based on REST, but it’s not HTTP. Same problem, right?

Not so much. In fact, it’s night and day; even just from the slideware, it’s clear that WAKA is an evolution of HTTP, improving and extending upon the capabilities, while pruning the extra bits that aren’t necessary. The underlying ethic seems to be to match HTTP function-for-function, but subtly improved in each case.

For example, the ability to specify the cache key directly — instead of using Vary headers, which treat the request headers as simple (and inflexible) strings — is incredibly useful and powerful, and only implemented as a proprietary extension by a few (very advanced) HTTP implementations today.

Meanwhile, Transfer gives you the bare minimum, with promises of more functionality via a “composable architecture.”

WAKA also uses the HTTP Upgrade facility, which implies that you’ll be able to run HTTP for interoperablity, and upgrade to WAKA when available on both sides of the wire. Try that with Transfer.

Is WAKA still vaporspec? Totally. Does it still have to overcome the inertia of HTTP by proving at least an order of magnitude improvement (which HTTPNG and others failed to do)? Yes. Still, Roy has a pretty good track record, and I’d put my money on him (especially when backed up by the ASF) over a bunch of vendors trying to sell “platform” any day.

In the meantime, HTTP is good enough to get work done with.

10 Comments

Bill de hOra said:

“an underlying protocol-independent version of HTTP.”

They lost me right there, in a “it’s not even wrong” way. What could that possibly mean?

Thursday, March 16 2006 at 3:31 AM

Mark Baker said:

It just means that it’s HTTP (re)invented two layers up. I agree it’s meaningless though, because WS-Transfer applications will be just as “tightly coupled” to WS-Transfer as HTTP applications are to HTTP.

Perhaps we should start referring to WS-Transfer as a transport protocol? 8-)

Thursday, March 16 2006 at 5:04 AM

Mark Nottingham said:

HTTP is already protocol-independent; you can run it on top of TCP, UDP…

Thursday, March 16 2006 at 10:25 AM

Robert Sayre said:

“Perhaps we should start referring to WS-Transfer as a transport protocol? 8-)”

I glad you mention this Mark, because I’m working on a new technology that takes protocol independence to the next level. I think WS-Transfer is too hard to use for everyday devs, so I’m developing XML-RPC-WS-Tranfer.

Friday, March 17 2006 at 6:09 AM

Mark Baker said:

Mike - what’s wrong with HTTP over MQ?

Friday, March 17 2006 at 10:25 AM

Mike Champion said:

I have nothing to do with WS-Transfer, don’t really understand its use cases, and just plain don’t care one way or the other what W3C does with the submission. My only reason for jumping in is that I don’t understand this assertion: “WS-Transfer isn’t a version of HTTP, it’s a competitor. It’s a diversion that keeps developers — in case they actually get interested in REST — on the SOAP ranch”.

How does WS-Transfer compete with HTTP? It’s a way of supporting RESTful application architectures in environments where HTTP alone is not an option. Do you think that all those enterprise MQ systems from IBM, Sonic, etc. compete with HTTP, and WS-Transfer is somehow going to postpone their inevitable conversion to HTTP intranets?

The punchline “WS-Transfer is HTTP over SOAP over HTTP” is funny, but nobody who wants to stay in business would even think of using WS-Transfer where HTTP itself is a viable option, for all the reasons y’all have blogged about. None of the people on the WS-Transfer spec are dummies, so it’s logical to assume that this overwhelmingly obvious point has occurred to them. Spin up a conspiracy theory if you wish, but I guarantee you that Evil Empire - Redmond Command Center has less than zero interest in breathing life into the IBM MQ infrastructure. The more plausible explanation to me is that the people behind WS-Transfer know that MQ et al aren’t going away, but some SOAP headers are proving to be useful in bridging HTTP and this REST-unfriendly infrastructure.

Ws-Transfer may well be a diversion, but I’d think you folks might find it useful as step 2 in a 12-Step Program https://en.wikipedia.org/wiki/12-step_programfor recovering SOAholics - “believe that a power greater than ourselves could restore us to sanity”. :-)

Friday, March 17 2006 at 11:09 AM

Chui said:

A lot of WS-* work seems to predicate on MQ being equal citizens with HTTP. Hence the reinvention of Security, Transfer, et. al, - things which HTTP already support well.

Is there a method to this madness? After all, gluing applications from components which you have little control over doesn’t help reliability. Dealing with SOA on MQ terms frames SOA in the language of unreliable services, rather than take-for-granted-service-is-going-to-be-available mindset.

Saturday, March 18 2006 at 4:40 AM

Robert Sayre said:

“some SOAP headers are proving to be useful in bridging HTTP and this REST-unfriendly infrastructure.”

http://activemq.codehaus.org/REST

I don’t know much about MQ, and the IBM products are probably a lot more ornate, but the ActiveMQ interface seems to be an existence proof.

Saturday, March 18 2006 at 9:16 AM

Mike Champion said:

Mark, beats me :-) I really don’t know anything about MQ other than a) reliable MOM protocols are pervasive in “enterprises” and b) I think MOM is what the WS-* people are referring to when they talk about “protocol independence”, not UDP vs TCP. I wish the WS-* specs would come with use cases; you’d think they would have learned by now that people on the Web side of things don’t understand what problems this stuff is supposed to solve.

I think the problem they are trying to address with WS-* is not so much the lack of features on any particular infrastructure; after all, HTTP has something akin to the WS-Transfer CRUD operators and MQ has more reliable messaging than WS-ReliableMessaging (and apparently can be made RESTful, as a couple of people pointed out). The point is to provide a higher-level protocol to avoid N x N mappings of the features of one to the features of another at the junction points.

But this is all speculation … has someone who actually wants WS-Transfer to exist blogged about its rationale? I poked around the other day and didn’t find one.

Saturday, March 18 2006 at 10:15 AM

Duncan Cragg said:

Roy Fielding is (still) working on Waka

Where can we go to learn about and get involved in this? If it’s still an active project, it would benefit from community input.

Monday, March 20 2006 at 6:27 AM

mark nottingham

other HTTP posts

other HTTP APIs posts

other Web Services posts