Argh!

Manageability blogs on The Imminent Rise of REST and Fall of SOAP. Yet, the author is either completely misinformed or intentionally making untrue assertions on the (non-existant) relationship between WS-I and the development of emerging standards relative to Web services.

Let me start with this quote:

"The sheer number of WS-I standards submissions is consuming the organization from within."

Huh? Which "standards submissions"? WS-I is working on 4 profiles: Basic Profile 1.1 (SOAP1.1, WSDL1.1, UDDI2.0 and a few related foundational specs and RFCs), Simple Soap Binding Profile 1.0 (SOAP1.1 and HTTP1.1), Attachments Profile 1.0 (SOAP Messages with Attachments and WSDL1.1 MIME Binding Extension), and the Basic Security Profile 1.0 (OASIS SOAP Message Security 1.0, and SSL/TLS).

It would seem that the author believes (incorrectly) that all of the WS-* specifications are "submitted" to, or being developed by WS-I. This is simply not the case. There is no relationship between WS-I and the development of proposed Web services standards. WS-I's mission is to improve the interoperability of Web services. It achieves this objective by developing profiles, testing tools and sample applications. The profiles provide interoperability guidance for the interoperable use/implementation of specifications/standards used in the context of Web services. The testing tools are used to test a deployed Web service and its artifacts for conformance with one or more profiles. Finally, the sample application implementations demonstrate the interoperability of implementations that conform to the profile guidelines. There is no standards development at WS-I, at least none to date.

The entry goes on to state:

Not only does WS-I have too many standards, what's worse, they have too many standards that have absoulutely no implementation. Implement first and then standardize on what you've learned, not the otherway around. History will record this endeavor as a classic case of a standards body going haywire.

There are so many things wrong with this statement it boggles my mind.

First, let me reiterate that WS-I does not have standards, much less too many. Second, WS-I only concerns itself with interoperability issues. Interoperability issues are by their very nature a function of multiple (two or more) implementations of a specification(s) which completely belies the suggestion that there are no implementations for the specifications for which WS-I is developing profiles.

Third, at least with regards to the set of specifications being developed by IBM, in collaboration with Microsoft and other partners, (IBM, Microsoft and other partners are only coincidentally also members of WS-I beause of our coproprate commitments to Web services) each of the specifications are being implemented and once a specification has been published, the authors conduct on-going interoperability testing of their implementations. The experience gained through both implementation and the interoperability workshops helps the authors refine and improve upon the specification. Hence, at least as far as IBM and its partners is concerned, we are pursuing exactly the course suggested (implement first and standardize what works).

Finally, as for the statement that "a classic case of a standards body going haywire" in reference to WS-I only serves to demonstrate that the author has no clue.

The reason that there are so many WS-* specifications is that there is no single source of these works. As a result, there are a number of competing initiatives covering similar or overlapping functional scope. Some of this is a function of the fact that there is no standard for (and much disagreement about) the standards development process; some believe that the way to develop a standard is by gathering 30-60 people around a conference table and developing by committee while others believe that standards should be based on proven implementation. In other cases, it is merely a function of people having differing technical beliefs or motivations. Finally, there are real and inescapable issues surrounding intellectual property which complicate and sometimes confound the community's ability to work together.