- Introduction
- The Standardization Part
- W3C and WS-I
- Microsoft, IBM, and Others
- The End User
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Microsoft, IBM, and Others
In looking over the variety of additional Web services specifications and proposals emerging, such as Microsoft's Global XML Architecture and those on IBM's AlphaWorks Web site, it seems pretty clear that when Microsoft and IBM agree, a specification has a good chance for wider adoption. When Microsoft and IBM cannot agree—for example, on business process orchestration (XLANG versus WSFL)—progress on the topic within the industry appears to stall.
One real difficulty is that Microsoft and IBM, as well as others in the Web services community, often pursue a kind of dual approach to try to speed up defacto adoption. They privately publish and promote specifications such as Web Services Inspection, Routing, Security, Reliable HTTP, and so on; while at the same time seeking to establish independent or dejure control over future versions of the specifications. This approach succeeded in getting SOAP and WSDL submitted to W3C, although their recent efforts to organize WS-I indicate that everyone may not be entirely happy with the rate of W3C progress on SOAP and WSDL.
The irony, of course, is that defacto and dejure standards are codependent. Unless a specification is under independent control (that is, not under the direct control of a vendor or group of cooperating vendors who can mold it to their benefit and to the detriment of others), many vendors and users won't adopt or invest in it. And unless a sufficient number of vendors and users adopt a standard and invest in it, dejure blessing is meaningless.
So where are we today? The core specifications—SOAP, WSDL, and UDDI—are widely accepted as being adopted, although WSDL has fewer fans than SOAP, and the public UDDI registry is on the verge of disastrous failure. UDDI is a great example of the chicken-and-egg problem that Web services in general must face, although in varying degrees. Without good data in UDDI, no one will use it. And if no one uses it, no one will bother to add good data. The problem is actually very broad because it gets into ontology, or categorization issues. Imagine trying to categorize all business worldwide, and you can easily see the scope of the UDDI problem.
But beyond the core specifications—which give you interoperability (SOAP), service description (WSDL), and service discovery (UDDI)—there is even less consensus among vendors with regard to adoption of additional technologies.
Sun has said that additional specifications for "enterprise quality" or industrial-strength Web services are not necessary because ebXML already provides them. The ebXML messaging service is based on SOAP with Attachments, so there are some grounds for viewing the remainder of ebXML as enterprise quality of service specifications on top of core Web services—but ebXML does not include WSDL or UDDI. Microsoft has said that it will never implement ebXML, and IBM seems to have ended up somewhere in the middle as a supporter of both (although I guess you could argue that IBM is big and divided enough to take a position both for and against ebXML, depending on whom you ask). Among Web services vendors, IONA and a few others remain more neutral, and support both initiatives.
The initial push behind the SOAP specification in early 2000 was to get it adopted by W3C, and thereby place it under independent control and ensure the kind of widespread adoption necessary for standardization. Everyone could agree upon the standardization of SOAP because the real money to be made is not in the basic transport or fundamental communication unit, but in the added value services and features over which everyone is currently fighting. The danger, of course, is that the fighting will somehow spill over onto the foundational specifications, and that an effort such as WS-I will end up hurting rather than helping the effort, especially if it becomes exclusive rather than inclusive.