Colliding Worldviews: Kitty Hawk vs. Indigo
By toddfast on Jun 06, 2005
For Microsoft, Indigo and the WS-\* stack form the basis of their .NET and Longhorn OS platform. If you look at the role of each of the WS-\* specs embraced by Microsoft, it becomes clear that each one is primarily a formalization of patterns, conventions, best practices, and designs that have been in use for years, if not decades. There really is very little new about WS-\* except terminology and syntax. For Microsoft, however, these specs allow them to build an open architecture to support all the things they want to include as part of their platform. The key question to ask, however, is who are the users of this platform? I posit that Microsoft will be the primary consumer, at least in terms of direct interaction with the WS-\* technologies. For others, Microsoft will deftly hide all of these details (and complexity) underneath developer-friendly APIs and components that may or may not involve Web service message exchanges. Does the developer care? In Microsoft's worldview, the answer is no. For Microsoft, SOA is the platform.
Kitty Hawk and several Web service proponents at Sun think in quite different terms. Rather, we (meaning Sun, not necessarily me) tend to think in terms perhaps best described as SOA is the application. This is consistent with Sun's track record with J2EE. J2EE was a success precisely because it directly put the tools of distributed computing in the hands of developers. The fundamental premise of the old J2EE worldview, and perhaps now the Kitty Hawk worldview, is that distributed computing is something developers care about directly. This manifests in Web service terms as developers wanting to construct and controls precisely the messages sent over the wire. For productivity, they want APIs that are modeled closely on these specific tasks. Sun gives developers APIs to construct a SOAP message and invoke a Web service; Microsoft gives developers APIs to invoke a method on an object like any other, but which may be exposed as a Web service.
One might argue that Indigo is an ill-fated direction for Microsoft and that perhaps they are missing the boat. After all, their previous efforts to bring distributed computing technologies (DCOM) to the developer masses were, for lack of a better description, squashed by J2EE. J2EE was in large part a reaction to the fact that Microsoft, as the 800 lb. gorilla, either had nothing solving problems in the same domain, or hid everything so well that developers couldn't peek under the hood to go beyond existing limitations. J2EE made distributed computing available to everyone, and generally it has been easier (in terms of capability vs. complexity) and more transparent than the alternatives. One may also argue, however, that J2EE's prominence at the forefront of developers' minds is coming to a close, and that it is now an inelegant, complex morass that complicates more than complements developers' lives.
However, there is evidence to support Sun's worldview that developers care about the deeper levels of the platform. Today, armies of consultants and corporate developers are employed to build enormous distributed systems using J2EE as the foundation, and there is an enormous information market surrounding it. These developers live and breathe distributed computing as digested and presented by J2EE, and in general, it works. Clearly there has been something right about the approach Sun has taken with J2EE.
Back to Web services: Kitty Hawk seems inclined to treat SOA and Web services as both means and ends: Web services have value in and of themselves as the way to write applications. Indigo seems to shy away from this grand scheme and instead treats SOA and Web services as merely a means to a different end: helping developers write apps easily using the Microsoft platform. Is the worldview difference attributable then to motive? I don't think so. Sun has as much interest in perpetuating the Java platform as Microsoft has in perpetuating its .NET platform.
I think the answer is instead a matter of philosophy around developers and tools. Inarguably, Microsoft deeply understands software developers en masse (and arguably, Microsoft understands them better than anyone else). If there's one thing Microsoft does exceptionally well, it is satisfy developers by giving them terrific tools to make use of the Microsoft platform. As evidenced by Steve Ballmer's legendary "developers, developers, developers" speech (which I think, unlike some, was stunningly brilliant), Microsoft's commitment is to the developer and in giving him easy-to-use tools that make his job easier.
Sun, on the other hand, has been historically less committed to the idea of ease-of-use and tools as a means to Java platform adoption. Capability to write certain kinds of applications has been the driving force behind Java and J2EE, and Sun certainly understands the developers that write these particular types of applicationss quite well. If I'm being intellectually honest, I must also say that Sun has often fallen short when it comes to appealing to the broader developer community via tools. For many reasons, historical and otherwise, Sun has traditionally thought of tools and their place in the developers' universe quite differently than has Microsoft. If the desired end result is an application, tools are the primary means to this end for Microsoft. For Sun, APIs have traditionally been the primary means to this end (though this is rapidly changing).
So the big question: is there anything wrong with either of these two worldviews? Perhaps, but not necessarily; each confers both advantages and disadvantages. But, these differing worldviews lead to some interesting schisms. Take for example the notion of Web service conversation. In the Indigo worldview, conversation is session, likely tied to the notion of transport-level connection (or perhaps its analogue using WS-ReliableMessaging and WS-Transport) and spanning one set of interactions between client and service. In the Kitty Hawk worldview, conversation is a broader abstraction that gives additional meaning and context to business data across multiple sets of interactions between clients and services, independent of transport and session. Both perspectives are valid, but difficult to reconcile. They lead the broader Web services standardization effort down paths with different conclusions.
Which of these worldviews is superior, and which will inflame the minds of developers to drive respective platform adoption? I'm not going to try to answer such unanswerable questions. I don't think the future is yet written, and if the past is any indicator, there are reasons to believe that both worldviews are viable and can coexist. Perhaps they are best described as the opposite ends of a spectrum between which different developer communities swing like pendulums. Now that Sun and Microsoft are officially cooperating on Web service standardization and interoperability, I think the most important result of this discussion is simply understanding these different, perhaps reconcilable--but perhaps irreconcilable--perspectives on the shape the Web services universe should take.