Anyone who doubts Microsoft is a world unto itself should have seen the thousands of loyal fans at the Visual Studio.Net launch last week, clapping obediently at the appropriate points and snickering gleefully at thinly veiled jabs to Sun's solar plexus. The huge video projections of Gates' mug reminded me of Apple's infamous 1984 Super Bowl commercial--except, in 2002, Sun would be the insurgent and Microsoft would play Big Blue. Only what would Sun smash the screen with? The "dot in dot-com"?
As I sat there daydreaming through video testimonials on .Net's excellence, I finally experienced sympathy for how Sun must feel: Microsoft really is bent on taking over the world and all this Web services hokum simply provides the convenient means to do so. Like a crafty, relentless chess player, Microsoft never stops fighting for the center of the board. The latest (and seemingly innocuous) move, which earned a PowerPoint slide in Bill Gates' presentation, was the launch of the Web Services Interoperability Organization (WS-I.org), a group dedicated to "promote Web services interoperability across platforms, operating systems, and programming languages."
That sounds like a standards organization, right? Nope. In fact, its main function is to promote best practices for Web services. The WS-I will offer "sample implementations"--which remind me of Sun's BluePrints, except that the prime objective will be to ensure Web services interoperability (which is fundamental to this whole machine-to-machine thing reaching critical mass). In addition, the WS-I will offer "profiles" that suggest how groups of Web services protocols might work together.
Which protocols are those? Here's where the plot thickens. No agreement has been reached on Web services protocols beyond the gang of four (XML, SOAP, WSDL, and UDDI), which together really provide a modicum of interoperability. Seems like the WS-I will run out of profiles pretty quickly. What other protocols might it be talking about?
Bear with me as we rewind to last October, when Microsoft announced several "WS" standards--WS-Security, WS-Routing, and so on--as part of a Global XML Web Services Architecture (GXA). From the beginning, Sun (which was dragged kicking and screaming into Web services) had been hammering Microsoft for supposedly ignoring Web services' security and authentication vulnerabilities. I had assumed at the time that when Microsoft introduced GXA, it was responding to Sun's criticism simply by saying "we control the .Net universe and these are the protocols we're going to use for Web services security, routing," and so on. But Microsoft was actually hunting bigger game.
See, GXA is a modular framework for additional security and business process protocols, so that Web services developers can simply pick and choose the protocols they need for specific Web services implementations. GXA is intended to be used by the entire industry and to capitalize upon the millions of hours that organizations such as OASIS, the W3C, OMG, and RosettaNet have put into developing everything from ebXML business-to-business schemas to XrML for digital rights management. You see the genius here: We're at a level above all this protocol stuff, says Microsoft, but here's how you should plug it all together. The WS-I may not be a standards organization, but when it starts putting together those protocol profiles, whose modular framework will they reflect?
If .Net offers many of the same benefits of J2EE, what we could be witnessing with GXA is a subtle imitation of the Java Community Process--not for .Net but for the Web services, XML layer. And just as Sun makes the final call with J2EE, Microsoft will hang on to GXA, keeping it out of the WS-I if possible. That will protect GXA from getting bogged down in endless round-robin committees. But it could also give Redmond a big advantage.
Sun, god bless it, has never seemed to capitalize much on being the arbiter of J2EE, at least if iPlanet's market share is any indication. But look how Microsoft has already capitalized on leading the development of Web services protocols. As of last week .Net is launched and in the air, with all the Web services pieces in place. By contrast, J2EE 1.4--the first version to formally incorporate Web services into the J2EE spec--won't arrive until sometime later this year. After that, it will take six months for J2EE vendors to make their products compliant with 1.4. How many enterprises will do serious Java Web services development in the meantime and risk forward incompatibilities?
Microsoft, with IBM as its supporter and beneficiary, clearly plans to extend that lead with GXA. Why else would Sun be the only big software company to shun joining WS-I? On the other hand, how can Sun afford not to join and be left out of the Web services game? Ouch.
But the choice is not as hard as it may seem. If you ask me, Sun should bite the bullet and join now. Microsoft's lead in Web services is significant only if customers demand them immediately--and so far, in a down economy, enterprises seem fairly reluctant to take the plunge. In contrast to the infant .Net, J2EE already has a large enterprise footprint and the Web services framework will get there eventually. Meanwhile, rather than drag its feet, Sun should get in there and help move things forward.
The irony in all this is that in a totally interoperable Web services world, switching costs will drop and Microsoft's lock on the desktop will loosen--and Redmond's dreams of trying to dominate the larger Internet world could easily stumble over its pervasive security and reliability problems. However it all turns out, I'm not going to miss this era of doldrums where the benefits of seamless Internet interoperability still seem a long way off. Let's forget the politics, launch those pilot programs, and get there sooner rather than later, even if Redmond scores the first few points.
Do you plan to use .Net to get your feet wet in Web services? Or will you go the Java route--either to experiment now or work with the fully cooked platform in 2003? E-mail Eric or Talk Back below.
