DARING INNOVATION IS not the reason why Web services will disrupt the status quo. It is easy to exchange XML-formatted messages via the Internet -- and that, of course, is exactly the point. In Act One of the Web drama, HTML forever changed how we publish and consume documents. In Act Two, now commencing, XML will likewise transform how business systems publish and consume business objects.
Pick an industry at random -- health care, for example -- and you'll find billions of dollars of inefficiencies waiting to be wrung out. The Web services movement will succeed in doing that because the technology is simple enough to become ubiquitous. It's not only big players such as IBM, Microsoft, Sun, and Oracle who are weaving the Web services "stack" -- SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), UDDI (Universal Description, Discovery, and Integration ) -- into their offerings. So are the smaller fry whose open-source toolkits (Perl, Python, PHP) power so much of today's Web. This universality is the key to the kingdom. It means the all-important network effect, which governs the success of any communications system, can play out again in the Web services realm. SOAP endpoints matter in proportion to the number of them that exist.
For software developers, the inflection point comes when routine programming tasks create and use Web services without any special effort, just as a matter of course. As Tom Yager notes, Microsoft's new framework and tools succeed brilliantly at making Web services straightforward for developers. But the revolution need not, and will not, wait for widespread adoption of the .Net Common Language Runtime and Visual Studio .Net. The trend on all platforms, and in all programming languages, is to radically simplify the construction and use of Web services. It is darned easy to advertise a SOAP method in Java and consume it from Perl, or vice versa, and to do these things on many different application servers and operating systems.
We can see the value of this genetic diversity as the security risks of a Microsoft monoculture grow daily more apparent. Crossing language and platform boundaries also paves the way for what may be the most disruptive long-term effect of Web services: the decoupling of domain expertise from programming language skill.
Today we think nothing of reading an ad in the newspaper for a Java or C++ programmer. But software is ultimately about the objects we use to model real-world domains, not the languages we use to represent those objects. The Web services approach kicks us up to the right level of abstraction. Because programming languages (as do operating systems) inspire religious devotion, this outcome might seem unlikely. But so did a universal cross-platform client in 1993. Things can change, and the technology of Web services looks like a powerful catalyst.