Windows

What .NET actually means for CIOs

You've seen hype, and more hype, about Microsoft's .NET Framework, but may be in the dark on what the system means for CIOs. As columnist Tim Landgrave explains, the bottom line is that .NET equals lower costs.

Perhaps no brand in the history of computing has been more mangled and misunderstood than Microsoft’s .NET. It’s been heralded as the replacement for COM, cited as the basis for all new Microsoft software products, and described as the killer of Java. Even Microsoft continues to vacillate on how to sell the .NET concept. Many CIOs simply have no clue what .NET is all about and the key advantages it offers.

Virtual machine technology
After renaming its next-generation, server-operating system Windows .NET Server 2003 last year, Microsoft recently did an about face and reverted the name to Windows Server 2003. The functionality of the new server operating systems hasn’t changed—it will still be the first server version of the Windows juggernaut that has the .NET Framework embedded in the operating system.

So Windows Server 2003 is now “.NET connected.” This new branding will indicate whether a product uses or interoperates with other .NET products from Microsoft or third parties. But it will take more than a branding change for most CIOs to begin separating the value of the concept from the hype.

The first key concept for CIOs to grasp is that the entire platform revolves around a central kernel that controls all access to a system’s resources. To understand the relevance, consider the existing Windows architecture. Windows gives developers several services and the Application Programming Interfaces (APIs) to access them. But any time developers need (or want) to access system resources (memory, ports, hardware) directly, they can “go around” Windows. Unless they correctly release these resources when they’re finished using them, though, the resulting inconsistency between the Windows environment and the underlying hardware environment is almost certain to cause a crash, memory leak, or other system-destabilizing event.

Moreover, although the Windows API is fairly consistent, the APIs for other services built on top of Windows (data access, message queuing, HTTP access, network programming, security) each has its own idiosyncrasies and learning curve.

The .NET Platform replaces this collection of system interfaces and entry points with a single core kernel that’s responsible for all access to hardware and systems resources. Applications developed on the .NET Framework are inherently more stable because the kernel can protect applications from stepping on each other. The interfaces to the kernel are presented as a cohesive, easy-to-understand, easy-to-extend, hierarchical set of classes. These classes not only represent a developer’s interface to hardware and system resources on the underlying system, but also wrap industry standard protocols like SOAP, WSDL, HTTP, SMTP, HTML, and others that allow developers using the .NET Platform to write code using its standard classes and allowing the Framework to provide the necessary translations.

Since the .NET Framework presents all of the hardware and system resources as a consistent, processor- and operating system-independent architecture, Microsoft (and other companies) can implement versions of the .NET Framework on operating systems other than Windows.

Microsoft has released versions of the .NET Framework for x86 machines running versions of Windows starting with Windows 98 Second Edition and for Windows-Powered Pocket PCs running MIPS, ARM, SH3, and Intel PA architectures. It’s even released an academic version of the .NET Framework running on BSD UNIX.

The three layers of .NET
The first layer of the .NET Platform is the Common Language Runtime (CLR), the kernel that manages access and permissions to system resources on behalf of all the programs executing on the platform. The CLR is conceptually similar to a Java Virtual Machine (JVM), with a couple of key differences.

First of all, where the JVM interprets Java Byte Codes each time the program runs, the CLR compiles applications the first time they run into native machine code and then executes these compile images on subsequent invocations.

The second major difference is that the CLR will support any language compiler designed for the .NET Platform.

So, rather than being forced to switch to Java, companies can leverage their existing language skills on the .NET Platform (including Visual Basic, C, C++, C#, Java-compatible languages, COBOL, ForTran, and another 20 specialty languages). The CLR provides a central point for security, language execution, memory management, hardware and system access, and other system services. The CLR loads, executes, and manages the programs developed for the .NET Framework, thus code run in this environment is called “managed code.” Developers may still call system services through an “unmanaged” interface provided by the CLR, but the CLR is able to shut down ill-behaved applications that use this interface.

The second and third layers of the .NET Platform are collectively called the “.NET Framework.”

The second layer consists of a set of core classes that give developers access to system resources like threads, strings, security contexts, network protocols, database systems, message queues, application management interfaces (WMI), raw XML protocols, and XML Web Services classes.

This layer of core classes allows developers to create robust, secure, distributed data management applications in a fraction of the time that it takes using existing tools to program against Windows and the myriad of system APIs. The time savings come from the .NET Framework’s ability to present a unified, consistent view of all of the underlying resources in a stable, manageable environment under the control of the CLR. Not only is development time minimized, debugging is radically simpler and more powerful. And the CLR minimizes the opportunities for developers to introduce hard-to-find memory leak or system resource management bugs by providing controlling access to the resources.

The final layer of the .NET Platform includes the various presentation management subsystems that compose the .NET Framework. The two key subsystems are the Windows Forms library and the ASP.NET library. The Windows Forms library encompasses a set of classes that include standard Windows controls (text box, list box, grids, etc.).

The Windows Forms library also allows developers to create their own high performance forms and controls in any .NET-compliant language that can be used “as is” or as the base from which new controls can inherit and add their own behaviors.

This capability allows corporate development teams to reuse key corporate presentation assets regardless of the original source language. The ASP.NET library manages access to Web-based .NET applications including XML Web Services interfaces and Web Forms. The ASP.NET Web Forms library provides functionality similar to its Windows Forms counterpart. Developers can create robust, precompiled, inheritable forms and controls that can be used in several different applications. An add-on to the Web Forms library—the Mobile Internet Toolkit—allows developers to create Web applications that will run on any Web-enabled device, including cell phones and Palm PCs.

The .NET advantage
So what are the compelling reasons for CIOs to investigate the .NET Platform? I believe it can be summarized in two words: lower cost.

Developers can create more robust applications in less time on the .NET Platform. They can reuse their existing language skill sets. The resulting applications are less expensive to manage and maintain. And the .NET Platform allows developers to create applications that adhere to industry interoperability standards like SOAP, XML, and Web Services in a fraction of the time required by other platforms.

If you’ve already made a significant investment in Microsoft technology in your organization, you should be making plans to move to .NET. If you’re a J2EE shop, you should at least understand how to integrate with .NET applications using SOAP and Web Services. You’re likely to be asked to do so in the next 12 months.

Editor's Picks