Wednesday, 15 March 2006
WS-Transfer, WAKA and the Web
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.