Commentary: Economy, Not Tech Fears, Slows .NET
A recent article in "BusinessWeek" reports that adoption of Microsoft's .NET technology was slowed more by economic conditions than technical roadblocks, such as a fear of transmitting secure data through Web services. This interesting analysis might explain how a company such as Microsoft, with $46 billion in cash and another $1 billion coming in every month from sales of the Windows OS and Microsoft Office products, could have failed so miserably to rally developers, enterprises, and consumers around a technology that builds on the company's core products. In markets in which Microsoft can't leverage its OS dominance, the software giant hasn't done well. For example, witness its failure to gain ground with living-room technologies, such as the Ultimate TV, Xbox (which is outsold 6-to-1 by market leader Sony's PlayStation 2), and MSN TV, or its weak attempt to enter the smart phone market. These failures stand in sharp contrast to the successes Microsoft has had with Office, Microsoft Internet Explorer (IE), Windows Media Player (WMP), and other products that build on the success of the Windows OS. You would think the company could produce similar success with .NET, which currently runs on--and requires--Windows. But .NET hasn't been a success, despite the fact that the company has spent billions of dollars wooing developers and users. As the "BusinessWeek" report notes, part of the problem is the economy: Microsoft introduced .NET during one of the worst economic downturns in recent memory. Another part of the problem is that .NET, unlike IE and WMP, isn't included in every new version of Windows. In Windows XP, .NET is optional, and it's still optional in Service Pack 1a (SP1a), the latest XP version. On the server side, Windows Server 2003 is the first Windows product to include .NET as a core, nonoptional component. But as a server OS, Windows 2003 will see relatively slow adoption. Incorporating .NET into Microsoft's core products is crucial to the technology's success because developers won't target .NET unless they know that many people have the technology. Installing a runtime environment such as .NET is hard and time-consuming, and users might forgo installing certain .NET-based applications if the installation process is too difficult. Today, developers can target .NET Web services and applications to Windows 2003. But .NET won't be a standard component of the Windows client until Longhorn, the next Windows version, ships in late 2005. .NET's role in the mobile front has been unclear, too. Until Microsoft released Windows Mobile 2003 for Pocket PC (the latest version of the company's Pocket PC software for PDAs), installing the Windows .NET Compact Framework, which developers can use to direct .NET applications and services to portable devices, was optional. Now, however, with Windows Mobile 2003, .NET is finally a standard ingredient. Microsoft's decision to "unbundle" .NET might not be surprising given Microsoft's legal troubles over bundling technology. But by detaching .NET from the success story that is Windows, the company has inadvertently stunted .NET's growth, introducing a technological chicken-and-egg scenario: Users won't see the value in .NET unless compelling products emerge that require the technology. But developers won't focus on .NET until the number of potential users is sufficient to warrant learning the new environment.
.NET Tech: OS-Independent Computing Strikes Again
Let's say you're browsing the Web looking for information about programming models and you come across this definition: " ... an architecture that enables pieces of programs to communicate with one another regardless of what programming language they were written in or what operating system they're running on." Sound familiar? It might, but that's a definition (according to PCWebopaedia.com) of the Common Object Request Broker Architecture (CORBA), not .NET. Both COM and CORBA solve some of the same problems that the .NET architecture solves. But one big difference between COM and CORBA and .NET is that COM and CORBA use Microsoft Interface Definition Language (IDL) files, but .NET does not. When a developer creates a program with COM, she writes a separate IDL file to accompany the program. The IDL file represents the interfaces that the server processes provide or require, listing both standard types for the language and any programmer-defined types that the application uses. (In this context, a type is "a type of data," which is important because programs work differently with data depending on what kind of data it is. As a simple example, if you type numeric data as numbers, then 2 + 2 = 4, but if you type the data as string data, then 2 + 2 = 22. With object-oriented programming, a developer can define new data types as needed.) When the IDL is compiled, the compiler can generate and write metadata to a file that client processes can use to discover which data types the program uses and the interfaces to those types. The IDL compiler also creates proxy objects that translate data types among machine architectures and among various execution models of programming languages. IDL-based architectures such as COM and CORBA work, but they have limitations that .NET is intended to mitigate. One difficulty with IDLs is that you must write them in C or C++, which complicates life for those who don't code in either language. Also, IDLs have only limited support for some facilities, such as method overloading (in which a class has multiple methods and the compiler chooses the most appropriate one for the parameters). A third limitation is that the metadata that the client processes use to identify the data types and their interfaces is separate from the IDL, which means that a developer might have a type's metadata (type library) but not its implementation files, or vice versa. The metadata might also be based on an old version of the IDL file, so it might not be consistent with the current type interfaces. Finally, the IDLs define the type interfaces, not the types themselves, so if the developer changes the behavior associated with a type, then that change won't automatically affect the subtypes below the interfaces. Again, these limitations don't mean that programming architectures that use IDL files don't work--such architectures been working for about 10 years. But using IDL files can lead to complications, and addressing those complications is part of the .NET architecture's mission.