The Looming Battle Over Web Services

by Bruce Silver

Looking back at wars of religion throughout history, it's often hard to comprehend the depth of emotion aroused by small nuances of belief. The same is true of the IT wars pitting Microsoft against its historic enemies, the forces of Java.

With each new generation of IT infrastructure, businesses are forced to take sides, often based more on philosophical principles than on provable merits. But once a company makes the choice, no amount of rational argument can shake its commitment to it. It becomes the company's new belief system - at least until the next generational cycle.

Such a generational change is just ahead, and businesses once again must choose their religion. The new generation doesn't yet have a name - I call it "loosely coupled e-business" - but the shared vision of heaven does: "Web services."

Web services don't really exist yet, but they are universally hailed as the next wave of software. The philosophical differences over Web services are thus at the heart of the next battle of IT belief systems: J2EE vs. Microsoft's .NET.

In the spring of 2000, just before the dot-com flameout and the ensuing e-business rethink, J2EE looked like it had the future all to itself. Even companies that had standardized on Microsoft as their client/server and intranet platform were moving to Java application servers like BEA WebLogic or IBM WebSphere as their standard for conducting business over the internet. The two key reasons: openness and scalability. Java components run on platforms from many vendors, including IBM, Sun and HP, which can scale up to the big-iron size needed for high-volume e-commerce. Microsoft components are basically a single-vendor technology running on servers that don't scale to the level of the Java/Unix offerings. As a platform for interconnecting multiple companies conducting real business over the Internet, Microsoft didn't really have a chance.

But openness as a vision and openness as a practical reality are two different things. Sure, Java APIs and Java objects can run everywhere across a multicompany business process, but object model-specific protocols like IIOP or RMI still require a homogeneous environment across the process, making multicompany solutions hard to build and relatively inflexible. Portability and interoperability, it turns out, don't always go hand in hand.

What is really needed is an infrastructure technology in which various components of a business solution can interact without knowing anything about the technical internals of the other components, even including where they are located or who is providing them. That's what Web services, at least in theory, will do. Instead of connecting these components by APIs, which are system-dependent, Web services communicate by simple XML messages using system-independent vocabularies and protocols.

It was Microsoft who first successfully promoted the Web services idea in its .NET announcement last year. Ironically, it was given a huge boost by J2EE stalwart IBM, who collaborated with Microsoft on the key XML Web services standards: SOAP, the protocol for communicating among Web services through XML messages; WSDL, the language for describing published Web services; and UDDI, the mechanism for registering and discovering Web services on the Internet. Today, other Java heavyweights, like Sun, HP and Oracle are talking up XML Web services and are incorporating Web services tools and components into their own J2EE platforms. In fact, the choice between .NET and J2EE now can be seen as a question of which will provide the better tools and runtime environment for future Web services.

In the Web services vision, a multitude of software publishers will develop useful bits of functionality as Web services and register them for use by other applications at a price. Businesses will also expose information from their own back office systems as Web services for integration within their own enterprise and trading community solutions. Business process solutions will be assembled from a combination of third-party Web services, in-house Web services (from each participant in the process) and custom code. For example, an e-commerce solution might integrate back-office systems across the supply chain through its own services while using third-party Web services to authenticate users, personalize content, and calculate taxes and shipping costs.

Microsoft and the J2EE suppliers generally share this vision, but there are subtle differences. Microsoft wants to provide the fundamental user-related Web services, centered around user identification, authentication and data-sharing permissions - an initiative known as Hailstorm. This suggests .NET has less to do with B2B commerce than with a redefinition of "personal computing" in the post-PC, mobile wireless Internet era in which software becomes a service rather than a product. On the other hand, IBM - the most voluble J2EE exponent of Web services - is squarely focused on enabling automatic machine-to-machine interactions over the Internet, particularly in a B2B environment.

These differences of emphasis, hazy as they are, hint at the inevitable divergence of the .NET and J2EE paths. Where .NET seeks to recast desktop software as Web services, J2EE seeks to automate B2B e-processes. This would seem to fit the traditional coexistence model, with Microsoft at the desktop and intranet level and Unix big iron in the back office and e-commerce. But will that fly? Recall that a year or two ago, IT executives were trying to standardize on a single Web infrastructure for the enterprise, not two.

Peaceful coexistence or another IT war of religion? It's too early to tell, but the evolution of Web services holds the key.

Bruce Silver (brsilver@earthlink.net) is president of Bruce Silver Associates, Aptos, CA, 831-685-8803. Reports are available at www.brsilver.com.