ANALYSIS
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-destabilising 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.
