In its first preview at the Microsoft Professional Developers Conference last fall, Windows XP successor Longhorn was shown running a 20-year-old copy of Visicalc. Ancient DOS software won't be the lone occupant of the Longhorn compatibility box. Win32, the Web, and even WinForms -- the .Net era's first GUI framework -- are all legacy APIs from Longhorn's perspective. Their replacements, Microsoft says, will jointly deliver "the best of Windows and the best of the Web."
The proof is still years away. But given the ambitious scope of the project, it's not too soon to consider how Longhorn will affect the vast majority of enterprises deeply invested in both Windows and the Web. How will the transition to Longhorn affect these twin legacies? Which aspects of the new system will embrace open standards, and which will entail lock-in? Will the benefits of the proprietary features outweigh cost? The answers differ for Longhorn's several subsystems; we'll consider each in turn.
One thing that's not in question, however, is Longhorn's deep commitment to .Net. The last time Microsoft said it was betting the company on managed code, the claim was heavy on marketing and short on substance. This time there's no wiggle room. Longhorn is deeply tied to the .Net Framework. Although its three "pillars" -- Avalon for presentation, WinFS (Windows File System) for storage, and Indigo for communication -- will rely on a mix of managed and unmanaged services, those pillars will export only managed APIs for use by Longhorn applications. That's great news for the long-term health of Windows, the productivity of its developers, and the security of its users.
To deliver these benefits, Microsoft is aiming a few years ahead of the hardware curve. Few of today's PCs and none of today's handhelds are likely targets for Longhorn.
Although the project may someday unify Windows, in the near term it will surely compound the already problematic fragmentation of the platform. As if that weren't headache enough, Microsoft's vote of no confidence in the future of many basic Web standards puts the company on a collision course with competitors who continue to invest in those standards -- and with customers who would like to see Web standards supported and advanced.
It's an aggressive and risky strategy. To appreciate the payoff, you can't just consider Longhorn's features individually, Microsoft says. The value of the system as a whole, the company insists, will exceed the value of the sum of its parts. Concept videos paint the big picture. In one of them, a real-estate broker uses Avalon's 2-D and
3-D graphics to visualize map data, WinFS metadata and contacts to assemble and share a package of information, and Indigo's XML messaging to tap into Web services and to collaborate peer-to-peer with investors and lenders. In the Longhorn-only world of the demos, rich-client applications flow to PCs on demand using the ClickOnce feature that will debut in the forthcoming .Net Framework 2.0, aka Whidbey.
The real world, of course, will never be Longhorn-only. By the end of the decade, Longhorn will be one of several viable Windows and non-Windows options. No matter which desktop OS predominates, there will likely be diversity within your enterprise and certainly among your business partners and customers. And the desktop is just part of an increasingly diverse IT landscape. In some ways Longhorn embraces that diversity, in other ways decidedly not. Although its pillars are complementary, each bears its own unique relationship to current technologies and standards. By teasing out those relationships, we can see where the proprietary lines are being drawn and can begin to assess the kinds of trade-offs Longhorn will entail.
The Indigo Wire
If you believe that Web services will be the lingua franca of network communications in the coming decades -- as TCP/IP was in past decades -- then you will regard Indigo as the least controversial of Longhorn's pillars. It is both solidly standards-based and aggressively innovative. Not all the standards that Indigo embraces are fully baked: Security, identity federation, reliable messaging, and transactions are among those still evolving. Even the SOAP transport at Indigo's core has yet to achieve ubiquity, and some wonder if it ever will. From a 50,000-foot view, however, there's broad consensus that some flavor of XML messaging will be the glue that connects services, applications, people, and devices.
Extending a tradition that dates back to Microsoft's earliest COM-based middleware, Indigo will offer developers hands-off control of the messaging system, enabling them to invoke asynchrony, transactions, or encryption using terse metadata annotations rather than many lines of code. The tools and frameworks that support this declarative style will be proprietary and, Microsoft hopes, compelling. But Indigo's charter is to ensure that the resulting applications and services can interoperate cleanly with any standards-based services fabric.
Two additional factors make Indigo especially noteworthy. First, it's the only Longhorn pillar that will ship for down-level clients, maybe even ahead of the Longhorn OS itself. Second, Indigo replumbs the networking substrate to make XML messaging efficient for local or peer-to-peer use. So, in theory, developers will be able to apply a single set of skills to Longhorn-only, Windows-only, and open environments. The devil is always in the details, but Indigo appears to offer maximal leverage with minimal lock-in.
WinFS Storage
Longhorn's storage system, WinFS, will attempt a feat never successfully performed on the mainstream desktop. It will interpose a relational database between NTFS and clients, as in both users and applications. And it will use that database not only to optimize searching but also to enable more flexible ways of organizing information. From a user's perspective, the distinction between search and navigation will blur. Conventional queries based on well-known properties -- document name, author, date -- will be accelerated. New kinds of queries will be enabled by relationships among properties. Because properties are owned by the system, applications will pool their use of them. And because WinFS does not model a tree but rather a directed acyclic graph, two or more folders will be able to hold the same instance of an item.
Working in concert, these capabilities mean that if appropriate metadata exists -- a huge "if," of course -- you'll be able to make requests such as: "Show me recent messages and documents related to project X." You'll be able to save that query as a self-updating folder. And you'll be able to take an item from that folder -- not a shortcut or symbolic link but the item itself, as represented by its WinFS ID -- and put it onto your to-do list without removing it from other places.
If .Net's theme is managed code, the theme of WinFS is managed metadata. And indeed, the two are joined at the hip. WinFS items are instances of .Net Framework classes. Applications declare them using a proprietary schema language and search them using a proprietary query language. Could XML-oriented schema and query languages solve the same problems in a more open way, leveraging the trend -- strongly evident in Microsoft's own Office products -- toward open document formats? Quentin Clark, director of program management for WinFS at Microsoft, argues why not.The relational core of WinFS is an operational necessity, he says, but he points out that WinFS and Yukon do share common SQL/XML code.
Here's the upshot. If you're investing today in XML document formats, you should expect WinFS to do a good job running XPath or XQuery searches over them. Of course you'd also like the system to translate between XML data and WinFS metadata. That way, an XML document produced by a non-WinFS-aware -- and perhaps non-Windows -- application could participate in WinFS relationships and behave nicely in the Longhorn shell. Clark says some translation will occur, but he does not yet know how automatic it will be.
The Avalon View
Avalon reboots Windows graphics to unify three modes -- documents, user interfaces, and media -- within a
single display stack. According to Darryn Dieken, group program manager of Avalon at Microsoft, the massive effort has already produced nearly 20,000 APIs. It's a top-to-bottom overhaul involving drivers, the services formerly provided by Win32's User and GDI (graphics device interface) modules and the XAML (Extensible Application Markup Language) programming toolkit. The goal, Dieken says, is to equip PCs in the coming decade
for efficient, seamlessly integrated display of "presentation experiences" that combine video, animation, 2-D and 3-D graphics, rich document display and editing, and compelling software interfaces.
Along the way, quite a lot of baggage had to be jettisoned. Avalon will run only on high-end PCs. A stripped-down version might be capable of running Windows CE, Dieken says, but "the spirit around Avalon is to exploit the PC as much as possible."
Similarly, Avalon plays on the Web only in the sense that ClickOnce deployment can send partially trusted applications to clients running the full Avalon stack. It makes no use of Web standards such as XHTML, CSS, or SVG (Scalable Vector Graphics) and indeed invents its own counterparts to these. Some observers initially hoped that XAML would support an alternate rendering for the Web. Clearly, enterprise developers seeking maximal reach for minimal effort would have loved that solution. According to Dieken, the Avalon team gave it a try, spending months working on an ASP.Net-like approach before concluding that no single model could adequately express both paradigms.
If you decide there's competitive advantage in giving rich Avalon experiences to your intranet or Internet users, Microsoft will dramatically simplify the task. But you'll have to do everything again -- and very differently if you also want to reach the Web. Although ASP.Net 2.0 can surely help, Microsoft is doing nothing to improve Internet Explorer's support for DOM, CSS, SVG, or other standard ways to enrich the browser. And despite the fact that open source critics assert that XAML need not have been bound inextricably to the proprietary Avalon stack, Microsoft sees no possibility of -- and no real motivation for -- a standard rich-client technology. "You can make an argument that the customer will benefit from the competition," Dieken says, adding that "it will be hard for some developers who have to make a choice."
For developers of commercial Windows software, that choice boils down to timing. Today, for example, more developers would like to use .Net, but they refrain because there is no end-user version of Windows that includes .Net as standard equipment. For enterprise developers, however, there's more to worry about than the center of gravity of the Windows installed base. Microsoft is careful to point out that Avalon is not a reach technology. But enterprises need reach and can ill afford to invest in a rich-client technology that forecloses that option.
The Whole and the Parts
Longhorn would make perfect sense in an alternate universe where the Web never happened, where phones stayed dumb, and where Windows applications owned the edge of the network. But in this universe nothing owns the edge. We have browsers, we have computerized phones, and we have a growing number of portable, rich-client technologies. Although Microsoft would like us to regard Longhorn as a unified whole that's greater than the sum of its parts, its pillars will intersect with enterprise IT in quite different ways.
Indigo, by virtue of its developer-friendly simplification of Web services protocols, could propel Microsoft into the forefront of enterprise middleware. Although Longhorn's use of Indigo will focus on networks of Windows peers, the technology isn't bound to Longhorn. Expect to see Indigo-powered "enterprise service bus" offerings from Microsoft and partners.
If WinFS succeeds in delivering improvements in users' ability to organize and manage local information, enterprises looking to drive productivity up -- and support costs down -- will want it. The wild card will be the level of support for legacy document formats and emerging XML formats. Benefits that accrue only to new WinFS-aware applications won't tip the scale.
Avalon's TV-like "presentation experiences" clearly favor the home entertainment center over the business desktop. An accelerated convergence of voice, video, and data could alter that equation, and Avalon is designed to help drive that convergence. But enterprises concerned about reach and lock-in will need to carefully evaluate the trade-offs.
How will things will play out? Check in in five years and let us know if our crystal ball was cloudy or clear.