email article
	printer friendly
	more resources

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.