Longhorn: What Should You Do Differently?
Where should you focus your attention in preparing for Longhorn.
by Brian Connolly

Tech•Ed, May 26, 2004

Longhorn, the next-generation operating system for Microsoft servers and client machines, is a major industry change that poses challenges for developers building applications for release within the next year to 18 months.

This isn't the first time the developer community has had to position themselves for a sweeping change by Microsoft. Recall "Cairo," "Chicago," "Nashville," and "Whistler"—the code names that signified the convergence of Windows and Windows NT, and the integration of Internet Explorer into the operating system. That caused great upheaval in the industry, but because these technologies primarily affected the end-user interface to Windows, there was only limited effect on application architecture.

Longhorn is different. Longhorn builds on the success of .NET and creates a new application architecture built entirely with managed code. Longhorn is explicitly designed with component security models and distributed applications in mind. It features a new filesystem, WinFS, coupled with a new natural-language search facility.

Microsoft's Recommendations
Microsoft's advice, in the "Developer Guide to Migration and Interoperability in 'Longhorn'" (see Resources), can be summarized as:

• Use a service-oriented architecture (SOA). This means separating an application into a set of components, each offering a messaging interface. These components can then be distributed across a network.
• For applications that must integrate with legacy components, build the main application using WinFX (the new .NET), and use one of three interop strategies (C++ include and import library linking, P/Invoke, or COM interop) to communicate with previously built, non-Longhorn components.

There's really nothing surprising in this advice. SOAs are a general industry trend (Tech•Ed is featuring numerous SOA-related sessions), resulting from declines in the cost of server hardware and the development of industry-standard Web services. You would be well advised to consider an SOA even if you're building a J2EE application on Unix and Linux servers.

Similarly, the recommendation on interop is fundamentally the same approach you would take with .NET applications. In other words, you can't prepare for Longhorn specifically. Just do what you would normally do building new applications in .NET.

Effect on Large Client/Server Applications
Microsoft's advice is fine in principle, but what if you're investing in a new client/server application today?

The server-side recommendation for an SOA makes sense, but you're probably already doing this. If you're deploying on a Windows Server platform, it's likely you're developing an SOA organized into business and data tiers. The only thing you must do to prepare for Longhorn on the server side is use .NET and either Web services or remoting. If you do this, your servers can migrate to Longhorn at a time of your choosing.

The client side can be much harder. It's rare that you can force an operating system upgrade as part of a client deployment. You need to design your applications in a manner that can take advantage of Longhorn where present, but can still provide value to customers when it isn't.

Longhorn isn't due out until early 2006 at the earliest, and it will likely be later. Given the reluctance of organizations to deploy Microsoft's operating systems until at least the first service pack, and realizing that it takes many years to upgrade millions of end-user machines, there's no good reason for you to architect a client application explicitly for Longhorn if you're building a client application now targeted at the public.

This is especially true because Microsoft is placing particular emphasis on backward compatibility. To demonstrate this, it used an extreme example during the initial introduction—running a 16-bit VisiCalc application inside Longhorn. So the client applications you're designing now—the ones you must design for users still running Windows 98—should work just fine under Longhorn.

So should you factor Longhorn into your client application architecture? The answer is similar to the answer on the server side. Build the application framework around .NET and continue to use standard, supported practices for unmanaged components. With this approach, you will be no more than one major release cycle behind Microsoft, which isn't bad.

Planning for the New Storage Model
The only possible area where you might want to factor Longhorn into the client application architecture is in its storage layer. WinFS is a revolutionary new storage model that will allow users to organize content not by the explicit storage in hierarchical directories, but rather around extensible metadata. And the notion of content is larger than just files—it includes messages and events as well.

WinFS has a notion of "sets," which are collections of content that share certain application-defined characteristics (see Getting Started with WinFS in Resources). The introduction of this storage model means that the current, explorer view of a hierarchical arrangement of folders will likely be supplanted by a new visual model, and you should definitely factor this model into your client application architecture.

One way you can do this is to offer a thin layer of set-like functionality by allowing users to organize content with application-defined metadata. You'll need to physically store content using the current filesystem, of course. But you can implement your own simple set logic using either a relational database such as MSDE or the Microsoft Index Server.

By adding a simple content-set model to your client application, you'll add value for your users, while aligning yourself with Microsoft's direction. When Longhorn is released, you can replace the custom-built content-set framework you've developed with the native support in WinFS and Longhorn.

About the Author
Brian Connolly is an independent consultant specializing in large-scale transaction systems. Contact him at http://www.ideajungle.com.