Ever since we published our WS-GAF white paper criticizing OGSI, its object-oriented nature and how it (ab)used existing technologies (XML Schema and WSDL), there has been a lot of discussion in the Grid community about WS-I. You see, we've always advocated for Grid solutions to be built on stable, existing, widely-accepted technologies. We started promoting the use of those Web Services specifications for which the WS-Interoperability organisation has produced profiles. To date, this means only SOAP, WSDL, XML Schema, HTTP, and WS-Security (oh, and UDDI).

I feel that the recommendation to build on stable technology is a reasonable one and I feel confident about it. In fact, the few production deployments of services built using WS technologies follow such an approach (e.g. Amazon, Google, the SkyServer, etc.). A lot of people seemed to agree with our suggestion and the "WS-I compliance" mantra has become really popular in the discussions within the Grid community. But what does it really mean?

After reading the "Less than a week to Globus TK 4.0" post over at the Grid weblog I felt that I needed to write something about WS-I and when I believe one can claim compliance with it. Please note that I have nothing against the Globus Toolkit or the team behind it. They have been responsible for many of the advances in Grid computing. This is about what I believe to be the wrong use of the term "WS-I compliance".

WS-I profiles define how existing WS specifications should be used in order to achieve maximum interoperability. The profiles effectively clarify the way existing standards should be used because the final documents were not clear in places or the flexibility they allowed was leading to interoperability nightmares. If the rules of WS-I profiles are followed, it is expected (but not guaranteed) that the resulting deployments would interoperate (at least as far as the underlying infrastructure is concerned).

Now let's look at WS-RF and WS-Notification on which GT4.0 is built. Both specs build on WS-Addressing (a great specification which, however, is not a W3C recommendation yet) and neither of WS-RF and WS-Notification is an OASIS standard yet (although they are very close). GT4.0 will probably be based on a snapshot of WS-RF, WS-Notification, and WS-Addressing and not on their final versions. How is the use of snapshots good for interoperability unless everyone uses GT4.0? The same applies to any other tool that follows a similar approach. Also, can we really say that all these specifications or that the services we build using them are "WS-compliant"?

One can build a specification according to the WS-I rules. There is no argument about that. In fact, I suspect that most (if not all) specifications do exactly that. But does adherence to the WS-I profile rules for writing an infrastructure specification mean anything unless everyone implements that specification? For example, in most likelihood WS-Coordination and WS-CoordinationFramework (or their transactions relatives) do not break the WS-I BP 1.1 rules. Does this mean that these two are interoperable? Absolutely not. Will 'Grid' services built on top of WS-RF be considered "WS-I compliant"? I believe not since my WS-I compliant tooling (e.g. Indigo) will not know about the behaviours and underlying specifications assumed by WS-RF and WS-Notification. If I want to interoperate with a service built on these specs I will effectively have to build the assumed behaviours from scratch. Is this what interoperability is all about?

I would call a tool or a service using WS-RF and/or WS-Notification (or any other infrastructure spec) as "WS-I compliant" only when the WS-I organisation produces a profile which includes these specs. Please note that the same applies for WS-Addressing (even though I happen to like this spec a lot) and any other specification out there. That's the state of Web Services today. We can only count on the simple ones. We have to be patient and help with the standardisation effort of WS specifications, the interoperability testing, the wide adoption, and user education before deploying them in our production environments. Of course this does not rule out experimentation with such emerging technologies.

I believe the "WS-I compliant" claim in such cases to be just marketing speak.

UPDATE: Few minor syntactic changes