WSDM as a standard – the other side

The commentary from Tim Bray (“Stop WSDM”), Grek Pavlik (“WSDM Standardization: Just Say No (For Now)”), Mark Little (“Why WSDM isn’t ready for primetime (yet)”), me, and I guess others made Mark Potts reply (“Response to Stop WSDM”).

First, my apologies to Mark for the lack of support for formatted comments on my blog. He originally tried to post his reply as a comment.

Mark supports the other side of the story expressed by those who criticised the decision to make WSDM an OASIS standard.

Although Mark and I have agreed on many things in the past, on this one I will continue to disagree with him. Of course, he’s an HP CTO and, hence, in a position to have a more in-depth understanding of the industry’s needs than me. On the other hand, since I am not affiliated with any company, I don’t have a direct interest in one way or another, so my comments are always based on what I personally think is good for the Web Services community. (Please don’t take that as a suggestion that Mark or the others are not interested in the good of the community… just clarifying my position).

I see early standardisation as a being bad for the community. When the WS-Addressing specification gets finalised, those trying to implement WSDM will have to support 3 different versions of it. Yes, the semantics of some of some of the elements have not changed (although References Properties do not exist at all now) but still one will have to make sure that messages with WS-Addressing elements from any of the 3 versions can be processed. Mark makes it sound as if it is something trivial to support: “it’s just a matter of accepting elements with the same local name but, coming in one of two namespaces” (“Response to Stop WSDM”). Directly processing the XML messages would allow a developer of WSDM to deal with the different versions but it also means that the same developer effectively has to own the entire WS middleware stack. If would be (almost) impossible to use Axis, WSE or Indigo unmodified in order to implement WSDM; control of the entire implementation of the tooling is necessary. This is bad for making interoperable tools and for the wide adoption of a standard.

We’ve seen this happening in the Grid world. The attempt to build the entire Grid architecture on OGSI took almost 18 months only for OGSI to become a GGF standard and then abandoned in favour of WS-RF. What was wrong with OGSI? Apart from the object-oriented conceptual model, it was not conformant to existing XML-specs or, according to some, was making “excessive use of extensibility mechanisms”. As a result, existing, widely-used tooling couldn’t be used without modification or new tooling had to be introduced in order to build high-level Grid services.

Then, we spent another 18 month waiting for WS-RF instead of building high-level Grid services on widely-adopted, interoperable, well-supported in terms of tooling, well-documented standards (i.e., those in WS-I Basic Profile and WS-Security Profile). As a result, the Grid community is split between those who want to build on WS-RF (I am not talking about the conceptual model here) and those who don’t want to adopt it. This is very bad for interoperability.

I think that the early standardisation of WSDM carries similar dangers in terms of wide adoption and interoperable tooling.

Comments are closed.