WS-Transfer, WS-ResourceTransfer, WS-Enumeration and WS-MetadataExchange on their way to W3C

A bit over a month ago, I mentioned my hope that WS-ResourceTransfer (WS-RT) would be allowed to rest in peace. This is apparently not to be and the specification is now on its way to W3C, along with WS-Transfer, WS-MetadataExchange and WS-Enumeration. This is not all that surprising and I had even hazarded a guess of who would join IBM in doing this. My list was IBM, CA, Fujitsu and Cisco. I got three out of four right, but Oracle replaced Cisco. The fact that the company I got wrong happens to be my employer is something I can’t really comment on, other than acknowledging the irony…

This is a very important development in the area of management standards. Some of the specifications listed here are used by WS-Management. They are also clearly intended to replace the WS-ResourceFramework stack that underpins WSDM. This is especially true of WS-RT which almost directly overlaps with WS-ResourceProperties. Users of both WS-Management and WSDM will take notice. As will those who have been standing on the side, waiting for things to stabilize…

If you are trying to relate this announcement to the WS-Management/WSDM convergence previously going on between Microsoft, IBM, HP and Intel (which is the forum in which WS-RT was originally produced), it looks like this is what the “convergence” has turned into. Except that three of the four vendors seem to have dropped out, thus my quotation marks around the word “convergence”.

The applicability of these specifications outside of the management domain seems to be assumed in this submission. It’s been often asserted but, in my mind, not yet proven. I don’t see the use of WS-RT by WS-Federation as a proof of this relevance (one of these days I’ll write a post to explain why).

It will be interesting to see how the W3C responds to this offer. The expected retort didn’t take long. If WS-RT wasn’t allowed to rest in peace, it won’t be allowed to REST in peace either. You can expect the blogosphere to light up with “WS-Transfer for RESTful applications” discussions (mostly making fun of WS-Transfer’s HTTP envy) very soon. Even though that’s just one of the many angles from which you can view this development, and not the most interesting one.

[UPDATED 2008/7/6: It took a little longer than expected, but the snarky/ironic blog posts have started: Steve, Mark, Tim, Bill, Stefan]

3 Responses to WS-Transfer, WS-ResourceTransfer, WS-Enumeration and WS-MetadataExchange on their way to W3C

So, instead of two islands (WSDM vs. WS-Man) we will have…. two islands? (Microsoft’s WS-Man vs. WS-Man with WS-ResourceTransfer)?

The basic thing about these specs is that they’re written as general purpose data access APIs. They’re arguably usable as a data access layer for your web services, if only you could adapt your existing services over a bus or expose another port type out of your WSDL. (This observation is in the Jazoon ’08 talk I gave this week).

In the short term, it looks like it’s going to be WS-Managment versus of hodge-podge of XML messages that draw from the current WS-RT draft and at least one eventing spec (either WS-Notification or WS-Eventing). In the longer term, it looks like it’s going to be the current WS-Management (not going away at this point) versus at least one WS-RT-based stack (that stack could be presented as a new version of WS-Management or not). I say “at least one” because seeing how little appetite there seems to be for practical compromise versus grandstanding, I wouldn’t be surprised if we end up with more than one effort to build management on top of WS-RT if/when (at this point it is not sure that W3C will accept it) WS-RT comes out. At this point I have stepped out of the train, but the wreck is almost as painful from the outside as from the inside.

WRT to your second paragraph, I am very interested in your Jazoon talk. I didn’t see anything about this on your blog since you announced that you were going. Do you plan to publish content from your talk? If not, can I request the favor of an email? :-)

I need to know more about your talk to be sure, but I think you are making a point similar to one I am currently developing in a blog draft. About the fact that the fragment-access and mutli-step-retrieval features don’t have to be limited to a few operations (“another port type”, as you say).

That blog draft has been gathering dust, but now that WS-RT is back in the news and now that you bring that up I’ll try to finish it over the weekend.

The audience of the talk was with Java developers that had not likely been exposed to the WS-Man / WS-RF side of things so the talk mostly just gave a brief intro of what they do. You can download a (poorly formatted!) version of the talk here, though if you want a better version I can email it. (Come to think of it, I may also send one to the Jazoon folks)