Who said WS-Transfer is for REST?

One more post on the “REST over SOAP” topic, recently revived by the birth of the W3C WS Resource Access working group. Then I’ll go quiet for a bit and let people actually working on it show me why I am wrong to worry about WS-RT.

Before that, I just want to clarify one thing. People seem to assume that WS-Transfer was created as a way to support the creation of RESTful systems that communicate over SOAP. As much as I can tell, this is simply not true.

I never worked for Microsoft and I was not in the room when WS-Transfer was created. But I know what WS-Transfer was created to support: chiefly, it was WS-Management and the Devices Profile for Web Services, neither of which claims to have anything to do with REST. It’s just that they both happen to deal with resources (that word again!) that have properties and they want to access (mostly retrieve, really) the values of these properties. But in both cases, these resources have a lot more than just state. You can call all sorts of type-specific operations on them. No uniform interface. It’s not REST and it’s not trying to be REST. The Devices Profile also happens to make heavy use of WS-Discovery and I am pretty sure that UDP broadcasts aren’t a recommend Web-scale design pattern. And no “hypermedia” in sight in either spec either.

A specification is not RESTful. An application system is. And most application systems that use WS-Transfer don’t even try to be RESTful. Mocking WS-Transfer for not being as good as HTTP to support REST systems is like mocking an airplane for not being as good as your hatchback for grocery shopping. It’s true, but who cares.

So let’s not reflexively attack WS-Transfer for assumed purposes. And similarly, let’s not reflexively defend WS-Transfer as a good way to build RESTful systems.

Just to clarify, this is not meant as a defense of WS-Transfer. I think that, at least in the context of its original purpose, it should be gutted to only its GET operation. The PUT and DELETE tasks should be handled by domain-specific operations. Which would have the consequence of making it look less like a REST wannabe. But my recommendation aims at improving its applicability to the management domain, not at making it comply to an architecture style that is not (at least currently) used in that domain.

4 Comments

Filed under Everything, IT Systems Mgmt, Manageability, Mgmt integration, REST, SOAP, Specs, WS-Transfer

4 Responses to Who said WS-Transfer is for REST?

  1. “I never worked for Microsoft and I was not in the room when WS-Transfer was created. But I know what WS-Transfer was created to support: chiefly, it was WS-Management and the Devices Profile for Web Services, neither of which claims to have anything to do with REST.”

    Don Box is one of the authors of WS-Transfer, so he WAS “in the room”. He had this to say about WS-Transfer (http://web.archive.org/web/20041112085142/http://www.gotdotnet.com/team/dbox/):
    [BEGIN QUOTE]
    We shipped the first drafts of the WS-Transfer and WS-Enumeration specs this week.
    Along with WS-Eventing, these three protocols provide some fairly general purpose application protocols on top of SOAP.
    Honestly, WS-Transfer has been in the oven for quite a while. It’s been interesting to see people’s reaction to it.
    Stage 1. What good is this?
    Stage 2. Ahh, the idea of uniform application protocols seems pretty useful.
    Stage 3. Wow, I can model my entire universe using less verbs/operations than I have fingers on one hand. Why would I ever author another WSDL portType?
    Stage 4. Ahh, the idea of uniform application protocols seems pretty useful. Specific protocols seem useful too, especially when I find myself overloading PUT to mean “reboot the machine and submit an audit record to my management log.”
    I can’t wait to watch the folks outside of building 42 go through the same four stages…
    [END QUOTE]

    Having discussed WS-Transfer with Don, I’m quite confident that his reference to “the idea of uniform application protocols” (a la Fielding’s uniform interface) is proof that REST strongly influenced the design of WS-Transfer.

    The Team Comment accompanying the submission of WS-Transfer leads to the same conclusion (http://www.w3.org/Submission/2006/04/Comment):
    [BEGIN QUOTE]
    There is an obvious parallel between WS-Transfer and the Hypertext Transfer Protocol (HTTP/1.1) and the Web itself:
    concept of resources which are manipulated via representations, similar to Web resources;
    the operations on resources are similar, with the WS-Addressing [action] property corresponding to the HTTP method:
    HTTP GET versus Get Web service operation;
    HTTP PUT versus Put Web service operation;
    HTTP DELETE versus Delete Web service operation;
    a Create Web service operation to enable resource creation corresponding to HTTP 201 responses following an HTTP POST or PUT.
    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.
    [END QUOTE]

    “WS-Transfer can therefore be seen as an underlying protocol-independent version of HTTP.” If duplicating the behavior of the HTTP protocol does have everything to do with REST, then I don’t know what would.

    I think it’s disingenuous to suggest that just because the initial use case for WS-Transfer is systems management, that it doesn’t “have anything to do with REST”. I’d rather see everyone acknowledge the relationship and thereby ensure that WS-Transfer is as RESTful (and Web-Oriented) as possible. It is, after all, a submission to the W3C.

  2. Hi Nick,

    Thank you for the well-researched comment. I have to assume that indeed Don gives a first hand account. In any case, he knows much more than me about the design goals behind WS-Transfer. I also notice that his ultimate stage (#4) specifically moves away from “all I need is these three verbs” and back to “it makes sense to use a ‘reboot’ operation to reboot a server”. So his logic in fact seems to align with my point: at first it looks like WS-Transfer is designed to be a HTTP-like restricted set of verbs on which you build your entire application (REST-like) but that eventually people realize that WS-Transfer is more useful as part of a larger system, one which also relies on specialized operations (like “reboot”).

    Can you point me to any real-life implementation of WS-Transfer that exhibits (at the level of the entire application) any convincing alignment with REST? The systems I know that use it (e.g. managing a bunch of WS-Management-enabled resources from a WS-Management-enabled IT management console) have no REST aspiration if you look at the entire system (and not just the WS-Transfer operations). And it’s the entire system that matters from an architectural perspective. If REST alignment was the real goal of WS-Transfer, you’d think some would use it that way. The only example I could find is just a code example/tutorial (nicely written BTW), not a real application.

    I am not saying that REST didn’t influence WS-Transfer in any way. I am hypothesizing that WS-Transfer was not meant as the sole protocol on which applications would be built, like HTTP. And if it’s not meant to be used that way, then it doesn’t make much sense to compare it with HTTP for that usage.

    WRT to the W3C team comment, they were handed that specification and on its face it does look like HTTP. So, especially from their point of view, it makes sense to assume that it meant to serve the same purpose. And to be of course pretty skeptical about it in that context (even though they put it down in very polite terms). But this is exactly what I say you shouldn’t do (which is why I pointed to that comment as an “assumed purpose”). If I am right that WS-Transfer is meant to be used alongside specialized operations (and Don’s stage #4 comforts me in this opinion) then one should consider the spec in that context and not as a tentative replacement for HTTP.

  3. I’ve never seen ANY use of WS-Transfer, which doesn’t surprise me since I don’t think it’s needed.

    If WS-Transfer is only to be used for WS-Management, why submit it or the rest of the WS-Management associated specs to the W3C? The W3C is the defender of the Web, not a systems-management standards body. The WS-* working groups don’t seem that interested in being “web compliant”, so why host its specs at the W3C?

    If the goal is to create a set of systems management specs based on WS-*, then there should be plenty of places to submit them. The W3C should be focused on ensuring that architecture of the World Wide Web is maintained and enhanced, not on dealing with a set of specs that is in many ways at odds with web architecture. I made a personal, impassioned plea about this issue a couple of years ago: http://www.w3.org/2007/01/wos-papers/gall . I still feel the same way (perhaps even stronger).

    BTW, The TAG just recently made this “at odds” observation again, wrt WS-Transfer: http://www.w3.org/2001/tag/2008/11/06-minutes#item03 . (The TAG discussion is very illuminating wrt their unease with WS-* generally.)

    What’s truly ironic here is that virtually every manageable device these days has a built-in minimal web server enabling it to be managed via http and virtually none have built-in support for the WS-* stack. Yet WS-Management wants to use the WS-* stack as the basis for systems management. I just don’t get it.

    Also, as to the need for a specialized reboot operation, it was my understanding that WS-Management was not heading in this direction. Instead the approach is to use a generic PUT or SET operation on a devices “state” to cause it to reboot. The history of systems management protocols (at least those inspired by SNMP) is very RESTful, at least in terms of a shared adherence to a minimal “uniform interface” philosophy.

  4. We agree on most things Nick. We agree that WS-Transfer is not needed (the re-usable GET is nice because its semantics are general enough to apply in many areas, side by side with domain-specific operations; the same can’t be said for PUT/DELETE if you don’t embrace the REST style). I have argued for a while that WS-Transfer is mostly useless. I see with interest that WS-Management is currently inlining WS-Transfer within itself to avoid having a dependency on that stand-alone specification. It’s being done there for the wrong reasons (politics around ISO), but the idea of WS-Management being more self contained pleases me, independently of why it’s being done.

    We also agree that there is no need (again, other than politics) for sending all these specifications to W3C. The W3C’s discomfort with this is pretty clear in the TAG minutes link you provide. When DaveO writes “membership wants to go ahead”, “membership” really means a handful of big companies led by IBM. That’s the kind of thing I was referring to in my description of the W3C campground (BTW, the TAG concerns in the minutes are mostly around WS-Addressing).

    WS-Management does not at all suggest to use WS-Transfer operations to reboot a machine. Section 9 of the spec (“custom actions”) is dedicated to the use of specialized, resource-specific, operations.