WS Resource Access working group starting at W3C

Things went quiet for a while, but the W3C Web Services Resource Access Working Group has finally taken life, as was announced last week. It’s a well-know PR trick to announce bad news on a Friday such that it goes undetected, is it a coincidence that W3C picked a Friday for this announcement?

As you can tell by this last remark, I have no trouble containing my enthusiasm about this new group. Which should not come as a surprise to regular readers of this blog (see this, this, this and this, chronologically).

The most obvious potential pushback against this effort is the questionable architectural need to redo over SOAP what can be done over simple HTTP. Along the lines of Erik Wilde’s “HTTP over SOAP over HTTP” post. But I don’t expect too much noise about this aspect, because even on the blogosphere people eventually get tired of repeating the same arguments. If some really wanted to put up a fight against this, it would have been done when the group was first announced, not now. That resource modeling party is over.

While I understand the “WS-Transfer is just HTTP over SOAP over HTTP” argument, this is not my problem with this group. For one thing, this group is not really about WS-Transfer, it’s about WS-ResourceTransfer (WS-RT) which adds fine-grained resource access on top of WS-Transfer. Which is not something that HTTP gives you out of the box. You may argue that this is not needed (just model your addressable resources in a fine-grained way and use “hypermedia” to navigate between them) but I don’t really buy this. At least not in the context of IT management models, which is where the whole thing started. You may be able to architect an IT management system in such RESTful way, but even if you can it’s too far away from current IT modeling practices to be practical in many scenarios (unfortunately, as it would be a great complement to an RDF-based IT model). On the other hand, I am not convinced that this fine-grained access needs to go beyond “read” (i.e. no need for “fine-grained write”).

The next concern along that “HTTP over SOAP over HTTP” line of thought might then be why build this on top of SOAP rather than on top of HTTP. I don’t really buy this one either. SOAP, through the SOAP processing model (mainly the use of headers, something that WS-RT unfortunately butchers) is better suited than HTTP for such extensions. And enough of them have already been defined that you may want to piggyback on. The main problem with SOAP is the WS-Addressing tumor that grew on it (first I thoughts it was just a wart, but then it metastatized). WS-RT is affected by it, but it’s not intrinsic to WS-RT.

Finally, it would be a little hard for me to reject SOAP-based resources access altogether, having been associated with many such systems: WSMF, WSDM/WSRF, WS-Management and even WS-RT in its pre-submission days (and my pre-Oracle days). Not that I have signed away my rights to change my mind.

So my problem with WS-RAWG is not a fundamental architectural problem. It’s not even a problem with the defects in the current version of WS-RT. They are fixable and the alternative specifications aren’t beauty queens either.

Rather, my concerns are focused on the impact on the interoperability landscape.

When WS-RT started (when I was involved in it), it was as part of a convergence effort between HP, IBM, Intel and Microsoft. With the plan to use this to unify the competing WS-Management and WSDM/WSRF stacks. Sure it was also an opportunity to improve things a bit, but 90% of the value came from the convergence/unification aspect, not technical improvements.

With three of the four companies having given up on this, it isn’t much of a convergence anymore. Rather then paring-down the number of conflicting options that developers have to chose from (a choice that usually results in “I won’t pick either sine there is no consensus, I’ll just do it my own way”), this effort is going to increase it. One more candidate. WS-Management is not going to go away, and it’s pretty likely that in W3C WS-RT will move further away from it.

Not to mention the fact that CMDBf (and its SOAP-based graph-oriented query protocol) has since emerged and is progressing towards standardization. At this point, my (notoriously buggy) crystal ball shows a mix of WS-management and CMDBf taking the prize overall. With WS-Management used to access individual resources and CMDBf used to access any kind of overall system view. Which, as a side note, means that DMTF has really taken this game over (at least in the IT management domain) from W3C and OASIS. Not that W3C really wanted to be part of the game in the first place…


Filed under CMDBf, DMTF, Everything, HP, IBM, IT Systems Mgmt, Manageability, Mgmt integration, Microsoft, Query, REST, SOAP, SOAP header, Specs, Standards, W3C, WS-Management, WS-ResourceTransfer, WS-Transfer

11 Responses to WS Resource Access working group starting at W3C

  1. What gives you the impression that “this group is not really about WS-Transfer, it’s about WS-ResourceTransfer (WS-RT) which adds fine-grained resource access on top of WS-Transfer”? WS-RT is clearly important to one of the participants, but it’s not yet clear how others will prioritize it, and what the REST people will make of it. (Microsoft would prioritize it at the end of the queue — interesting features for the next generation, but they need to be thought through and integrated more cleanly with Transfer than in the RT submission).

    Also, the problem with the “HTTP over SOAP over HTTP” dig at WS-Transfer is that one primary purpose of SOAP is to be protocol neutral. SOAP is increasingly used over transports such as UDP or JMS (and there are efforts underway at OASIS and W3C to standardize these bindings). Another way to look at this is that WS-Transfer makes *non*-HTTP environments more REST-friendly.

    BTW, my crystal ball sees the same future you do for WS-Man and CMDBf :-)

  2. Hi Mike. You may be right. But since the creation of this group has been driven by IBM (who doesn’t care much about WS-Transfer but wants WS-RT), the most natural thing to expect is that IBM will put the most resources (no pun intended) in WS-RAWG and will drive WS-RT there. And that the “REST people” that you mention will stay far away from this group. But we’ll see. I guess to a large extent it depends on whether/how Microsoft decides to participate in the group (you know the answer to that, I don’t).

    I agree that WS-RT does not cleanly integrate with WS-Transfer. It just pretends to do so in order to be able to present itself as a successor to WS-Management. If the group is really serious about layering WS-RT cleanly on WS-Transfer, it needs to better use SOAP headers and convince IBM to stop repeating “application data goes in the body”, especially when they can’t define “application data”. The fragment support mechanism in WS-Management is a better (but not great) approach. XMLFrag is an improvement on top of WS-Management’s fragments.

  3. Still with this “WS-Addressing is the root of all evil” stuff? People have been using WS-Addressing (both Member Submission and Rec) for a while now and you know something? The world hasn’t ended (attempts to blame the current world financial crisis on the use of WS-Addressing seem specious at best). This continual harping on the necessity for there to be one and only one way of identifying resources seems, well, *unnatural*. In my experience, that’s just not the way IT/CS works. Maybe I’m wrong, but it seems silly to keep yammering on about it.

  4. Hi Gil. You obviously haven’t heard of the memo (titled “house prices might not go up forever: analysis of possible impact of a downturn”) that came out of the Lehman Brothers risk analysis team and never made it to the CEO office because of a WS-Addressing version mismatch between the two systems. Or that article (titled “potential conflict of interest of credit rating agencies”) that retirement funds managers never got to read because of WS-Addressing headers not being properly handled by the Web-centric CMS.

    There are plenty of bad things out there that haven’t caused the end of the world. “Didn’t destroy the world” is a pretty low bar.

  5. Stu

    I wouldn’t discount the emergence of a RESTful RDF-based IT model emerging sooner than expected. Certainly it’s not a mainstream approach, but I think the ability to execute with it will be much greater than CMDBf and WS-Man. The product features available with such an approach are inspiring.

  6. Stu: amen. I am interested. But not as optimistic as you.

  7. being the author of the “HTTP over SOAP over HTTP” post quoted here, i liked the comment about looking at that new WG as bringing REST to non-HTTP environments by layering it on top of SOAP. that is a very optimistic way of looking at it, but it is interesting.

    however, i think the HTTP-based RESTful approach has a pretty good track record of building robust, large-scale systems that work well in practice. building an alternative REST universe on top of SOAP is certainly possible, but i think you would have to have really really really good arguments as to why you shouldn’t rather implement RESTful architectures in the HTTP world where there is an enormous infrastructure already existing.

    could somebody point me to a resource that explain why HTTP-based REST is not an option for web services? i am really curious, and i am sure there must be some discussion going on somewhere. an admittedly quick look at the WS-Transfer and WS-RT really looks to me like a “let’s create HTTP and media types and fragment identifiers and Atom and AtomPub” agenda, and i would like to understand better what i am missing here.

  8. Hi Dret. I think it is possible to follow REST principles over SOAP, but practically difficult because it’s very different from the way SOAP is typically used. The first step, of course, would be to ditch WS-Addressing (at the risk of making Gilbert roll his eyes again). Overall, it would take a lot of discipline.

    Whether it makes sense to attempt this or not, I am not sure. In the IT management domain, if I was to build a REST system, I would probably do it directly over HTTP, not SOAP. Whether there are other domains (e.g. banking with more stringent security/reliability requirements) in which a SOAP-based approach to SOA makes sense, I don’t know.

    But I am not trying to build a RESTful system for IT management (if Stu is right and it happens, then I’ll be more than happy to join though). More importantly, I don’t think that the people who built WS-Transfer were trying to either. They just wanted an easy way to retrieve config data from printers and servers. They were perfectly happy with these printers and servers having their specialized “start”, “stop”, “reboot”, “sleep” operations. I don’t know that they had even heard of REST.

    It’s only later (I think, some MSFT people who were in on WS-T from the start can confirm/correct) that some looked at it and assumed it was an attempt to follow REST over SOAP.

    You’re also asking for resources that describe why HTTP-based REST is “not an option for web services”. I don’t think there is any. What you can find, is resources that explain why it may not always be the best option (and usually present SOAP or other middleware-based approaches as the alternative). Sanjiva is one of the spokespeople for this approach. Or his colleague Paul Fremantle.

    Steve Jones is another a smart guy with non-religious thoughts on this. As is Stu. Here is what a search on “SOA REST” on Stu’s blog returns. Steve Jones, Stu and Steve Vinoski had a bit of an argument around these topics over the summer. In this post I provide links to the different posts in their argument (and a suggestion that they are not that far apart).

    Overall you’ll find more people who agree with Steve Vinoski and argue against the value of WS-* in most cases. The most eloquent being Pete Lacey, but he seems to have departed the topic. You can read or hear him on this at InfoQ, but in your case it would probably reinforce your current position. You may find it more interesting to hear people with different opinions.

  9. i totally agree that REST over SOAP does not a whole lot of sense. SOAP was born as a means to implement classical middleware/integration systems over an HTTP transport, and even though it is always repeated that you can do REST over SOAP, in practice nobody ever does it. and if you did, the question really would be wy not to use just HTTP, where you can get huge network effects by working on that level rather than just tunneling data over the web.

    on the other hand, if the goal is not to build a RESTful loosely coupled system, then SOAP might be a good idea, it allows to continue the past two decades of middleware/integration systems. even though it is questionable whether this integration-style approach is appropriate anymore in a world that is changing increasingly fast, and IT systems need to keep up with that. but that is an entirely different discussion…

    i am a web person and not an enterprise IT person, so i am definitely missing some background in the “old days of IT computing”. but it seems to me that the big issue really is around the question whether the old strategy of “integration” is appropriate anymore, when a more loosely coupled “cooperation” architecture is possible. which is not the always the case, and for the scenarios where tightly coupled integration is required, SOAP might be good.

    it was just this image of “SOAP as the way to bring REST to the non-HTTP world” that worried me, because so much of SOAP is so explicitly non RESTful that it does not sound like a terribly good idea.

    so i guess this means i am still looking for references to explanations what exactly HTTP is missing that RESTful web services need. is it that HTTP uses URIs and this WG is about defining something that instead uses WS-Addressing?

  10. Stu

    dret — coming from the enterprise world, I would say the most glaring ‘missing’ aspect in RESTful web services is a way to manage describe & handle structured data beyond media types and XML schemas. I think RDF, OWL, and SPARQL are good solutions to the problem, but there are many conceptual barriers in the way of their adoption.

    Secondly, I think a media type that can describe both human & machine-to-machine interactions and processes would be a huge win. Think of (without cringing/laughing/fainting) a cross between WS-HumanTask, BPEL, Atom/Atompub, XForms, and OpenSocial. Optimistically, it’s bursting the silos of services and BPM by putting it on a very flexible and decenatrlized foundation. If you’re a pessimist, think of it as a “bureaucracy construction kit, that sucks less”.

    Third, a MIME content-level signature & encryption protocol would be nice. Think S/MIME but actually designed for HTTP and multi-party exchange.

  11. Pingback: William Vambenepe’s blog » Blog Archive » Who said WS-Transfer is for REST?