In-Depth

Longhorn debuts, but few pay attention

Over the past three years, Jeff Parker has rewritten more than 60% of his company’s financial reporting applications to help it comply with Sarbanes-Oxley. Central to that strategy was adopting the Microsoft .NET Framework. “The key requirement of Sarbanes-Oxley is that any change in any code, interface, date or time that deals with financial data must be tested and documented clearly,” says Parker, a software team lead for a global Tier-1 automotive manufacturing supplier. Because .NET enforces more rigorous, object-oriented software engineering practices, he believes the new code could generate more reliable audit trails.


Fast forward several years, and Microsoft is now openly promoting the successor to .NET. Code-named Longhorn, the platform encompasses Microsoft’s next-generation Windows operating system. Having benefited from .NET, does Parker’s company now anticipate similar benefits from Longhorn, and are they ready to embrace it?

“I’ve been looking at it,” says Parker, who qualifies his answer with an admission that, as part of his offline role as board member of the Michigan .NET Users Group, he tries to stay current with the state of the art. However, when it comes to gauging the impact of Longhorn on his company’s core business, Parker is more reticent. “I haven’t looked at it intensively because I know our industry will move very slow before going to Longhorn,” he says.

When Microsoft raised the curtain on the developer preview edition of Longhorn a year ago, it became readily apparent that this was not just another incremental upgrade. For starters, Longhorn would finally make good on Microsoft’s 10-year dream to revamp the core file system, simplifying the retrieval and aggregation of data, regardless of whether it is a text document, spreadsheet, database entry, e-mail, instant message or multimedia file. Unlike Windows 2000 or XP, it would also contain new features such as capabilities for communicating and managing deployment of Web services, and the replacement of APIs that would extend the richness of Windows client user interfaces to the Web.

Microsoft released the pre-alpha code to developers with several caveats. First, it did not guarantee that any of the features would actually show up in the final version.

More importantly, Microsoft didn’t commit to a release date. It was only this past August that Microsoft finally showed its cards by announcing it would release Longhorn sometime during the second half of 2006. In addition, the company said it would extend some key features of Longhorn to existing Windows XP and Windows 2003 Server platforms. However, to get Longhorn out on time, Microsoft was indefinitely postponing release of Windows File System (WinFS), the next-generation file system that was supposed to be a pillar of Longhorn.

According to Daryl Plummer, group vice president and research general manager for software infrastructure at Gartner, Microsoft has succeeded in getting out the word about Longhorn. “They [customers] are aware of Longhorn because of Microsoft’s promises that it would replace the Windows 32 API that has been around so long, and because of the nicer integration and flexible deployment,” he says.

However, unless your company is in the software business, Longhorn probably remains a back-burner issue. “First, I must devote time that’s relevant to me at the moment,” explains Jay Glynn, development manager for a large insurance company, and co-author of several books on the Microsoft .NET Framework. “It is so far out, that what I see now is nowhere close to what will get released,” notes Glynn, who predicts his firm would probably not start using Longhorn features until at least a couple of years after it hits the street.

By contrast, technology vendors like Best Software, which just reengineered its popular ACT! contact management program around a .NET-based architecture, are paying closer attention. According to Paul Selby, senior product manager for ACT!, a key motivation is that Microsoft tends to throw more support toward newer platforms. Selby also saw real value in what Microsoft was planning, at least prior to the firm’s August announcement.

“The one feature that was of most interest to us was WinFS because it’s a common problem for people to work with something in ACT! and then lose track of it,” he explains. Until now, Best has been adding its own features, such as a supplemental database, to perform part of the trick. Given that Microsoft is delaying WinFS, it will have to continue picking up where Microsoft is leaving off for some time to come.

Wrenching change in look and feel of apps
As originally described by Bill Gates (in a speech before the 2003 Microsoft Professional Developers Conference), Longhorn would merge various security and networking enhancements from Windows 2003 Server and XP, provide tighter control over the cumbersome Windows Registry, and add features -- such as the ability to transfer an OS system image from one computer to another -- from third-party vendors such as Altiris.

More important, for developers, it would build on and, in some cases, change features introduced by Microsoft with the .NET Framework. With .NET, Microsoft absorbed the object-oriented innovations of the Java 2 Enterprise Edition (J2EE) framework and upped the ante.

Longhorn will consolidate tens of thousands of interfaces that have proliferated as Windows has developed over the years, theoretically simplifying aspects of software development. Longhorn will also make it easier to specify the performance, behavior and routing of Web services messages. So far, so good. On the other hand, it will wreak major changes to the way software developers design the look and feel of applications. Specifically, it will replace the Windows Forms and Web Forms introduced with .NET a couple years back with new frameworks that seek to blend Windows with Web and mobile clients.

Although Longhorn’s 2006 release target seems a long way off, given that the announcement comes barely a couple of years after its last major software development platform rollout, customers could be forgiven for feeling a bit rushed. Nonetheless, in actuality, the time between releases will likely stretch at least four or five years.

Not surprisingly, software development organizations have only vague ideas of what Longhorn will offer, and conflicting opinions on whether those features will be valuable. Glynn anticipates Longhorn’s Indigo feature, which blurs the differences between local and remote applications, could be extremely useful especially for systems used by remote workforces. However, Parker, whose financial reporting systems only deploy Web services internally, has little use for Indigo features for specifying performance, response time or security, because those are primarily aimed at services traversing the uncertain environment of the public Internet.

Longhorn’s Avalon feature, which addresses user interface development, could make it possible for Web-based information providers to add local, disconnected Windows clients for customers. “We could sell a different product offering,” says Steve Forte, CTO and co-founder at Corzen, a New York-based firm that specializes in syndicating employment data for clients in media, advertising and financial services fields. Nonetheless, he expects the market for such a product to be limited.

A key component of Avalon, providing a specialized XML tool for GUI development, could enable software organizations to more effectively separate front-end development from business logic. “For a consulting company like ours that doesn’t pretend to be artists, designers could work in the team without stepping on everybody’s toes,” ventures Tim Huckaby, founder and president of InterKnowlegy, and a frequent speaker at Microsoft forums. Glynn agrees that such a goal would be admirable, but would require breaking stubborn habits.

The open-source community is divided on the impact of Avalon. Some fear that extending the Windows client to the Web will, in effect, make Web applications proprietary. “What makes Longhorn dangerous for the viability of Linux on the desktop is that the combination of Microsoft deployment power, XAML [Avalon’s XML development tool], Avalon and .NET is killer,” writes Novell’s Miguel de Icaza, creator of the Linux-based Mono desktop environment that runs .NET applications, in a recent blog. “It is what Java wanted to do with the Web, but with the channel to deploy it and the lessons learned from Java mistakes,” he adds.

Nigel McFarlane, who also consults to the open-source community, disagrees, characterizing XML-based user interface languages as “seductive ways to escape HTML for a better GUI.” He concludes they are “not necessarily Microsoft-specific.”

A clue to the potential value of XAML comes from early experiences with XML languages now emerging in the Java world from providers like Macromedia and Lazzlo. After Optimal Payments, a credit card and debit processing company, began using Macromedia’s Flex XML user interface tools, it found customer complaints over poor navigation and workflow declining. According to the firm’s senior developer, Stacy Young, user interface development was traditionally an afterthought.

“It always got the short end of the stick,” Young notes. With Flex, front ends can now be developed in parallel with the business logic by design specialists, leading to better results.

Changed lives for developers
For Microsoft customers, the issue of adopting Longhorn is probably more a question of when, rather than whether.

“We only got rid of our last Windows 95 boxes this year, so it will be a long while before we adopt Longhorn,” says Parker. Instead, he is looking forward to the next version of .NET, which will enable his team to grind out Web-based financial reports easily, thanks to a new master Web page template feature.

Although Longhorn will introduce significant change in Microsoft shops, in some areas, Microsoft is not necessarily breaking new ground. For instance, Indigo packages much of the same functionality currently available from the Enterprise Service Bus products in the Java world. The same goes for Avalon’s XML-based UI development tools, not to mention its support for richer Web interfaces, which Java attempted with applets and third parties, such as Curl, tried through promoting their own proprietary toolsets.

Arguably, .NET’s changes were more profound because they required Microsoft shops accustomed to the loose rules of Visual Basic to adopt stricter practices for features as trivial as file naming, or as profound as object-oriented design.

Nonetheless, bleeding edge or not, Longhorn will change the lives of software development organizations -- in many cases, for the better. For instance, Avalon’s specialized GUI development tools could help organizations to become more agile now that they have tools to separate the development of front ends from core business logic.

The Longhorn question boils down to whether customers are braced for yet another round of change. With many organizations only now ramping back software development activity after a post-year-2000 hiatus, it could be argued this is a perfect -- or horrible -- time to consider change. Either way, the question is academic. Given that Longhorn remains several years off, it is understandable that few Microsoft customers can definitively state what Longhorn will do for their business.

Please see the following related stories: “The basics of Longhorn” by Tony Baer “A look forward, a look back ” by Tony Baer

DISCUSSION POINT: Is Longhorn going to be worth the long wait? Post your views on the Discussion board below.

 

Most   Popular