| December 2, 2008 11:00 PM PST | |
by Ziad Kaakani
Software Engineer
e-Business Solutions Lab
Intel® Technology and Research Labs
Fast-forward several years into the future and you will witness the transformation of computing into a truly distributed environment that is exploited by non-computer savvy users. Consider a personal calendar that is updated automatically to reflect travel plans upon the purchase of an airline ticket, and have the calendar information available on any computing device you log into. Such an application requires the integration of distributed services through a network of computers that could even be running different types of operating systems. What makes such an application possible is a set of distributed software components or objects that can communicate and exchange information via standard Web formats without the need to know how the components themselves are implemented or what computer language is used. It requires an Internet that goes beyond serving Web pages to browsers to one serving geographically dispersed services to applications.
The Microsoft* .NET initiative is aimed at realizing this computing environment and bringing its services out from the corporate boundaries and into the masses. Microsoft and other industry leaders are approaching this undertaking by first standardizing a framework under which applications will execute.
This paper does not cover the whole .NET initiative. It focuses on the seed from which this initiative grew: the Common Language Infrastructure (CLI). CLI provides a multi-language environment for building, deploying, and executing Web-enabled applications. It also defines a Virtual Execution System (VES) that enables application modules to be independent of operating systems and hardware platforms. Finally, although CLI is language independent, C#* (C-Sharp) is designed to be the best choice language for this environment.
Before dwelling on the details of CLI, let's explore the journey covered by the bits of a .NET application. First, a developer writes the source code using one of the .NET supported languages, such as Visual Basic*, C++*, C#, JavaScript*, COBOL*, Pascal*, Eiffel*, Python*, APL*, Perl*, and so forth. This code is then compiled using a .NET compiler to produce Portable Execution (PE) files that appear much like .EXE or .DLL files. This compilation task differs from the traditional ones in that, instead of producing native binary machine language representation of the code, it produces Common Intermediate Language (CIL) code that represents the desired functionality. This low-level pseudo language is an abstraction from the operating system and is not tied to the hardware platform.
Along with the CIL, the compiler also emits metadata and stores it in the PE files. Metadata describes the compiled code so other assemblies or applications can easily import it or tap into its details; for example, metadata describes all types and methods found in or referenced by the code.
Portable Execution files and other needed resources such as bitmaps, wave files, etc., are then packaged together to form an Assembly that represents a distribution unit. Versioning information is stored in the assem bly to ensure correct code dependency and compatibility. In the simplest form, an assembly may be comprised of only a single Portable Execution file.
At execution time, the assembly bits are passed to the Virtual Execution Engine (VES) that is also referred to as the Common Language Runtime (CLR) under Microsoft's implementation of the CLI. The VES loads and starts executing an assembly using a just-in-time (JIT) compilation scheme that transforms the CIL into native binary code. References to types in another assembly as specified in the metadata cause that assembly to be loaded and executed. Another important aspect of this runtime engine is its memory management system that shifts the burden of memory allocation and freeing from the application developer to the runtime engine, thus creating a more reliable and robust environment.
You can see that a .NET application can be written in any language as long as its compiler can emit the CIL, and it can run on any platform as long as a CLI is implemented on that platform. The depiction for this architecture, the CIL, and the VES all fall under the CLI specification. Additionally, the CLI defines a set of class libraries covering a standard set of data types, as well as classes that deal with a wide range of functionality including input/output formatting, IO, networking, security, and XML. This allows developers to build upon this standard base to produce powerful applications. The following diagram illustrates the components that make up the CLI.
At first glance, this architecture may appear similar to the Java Virtual Machine* (JVM*) architecture. In fact, the concepts of class loader, memory management, garbage collection, intermediate language, just-in-time compilation, and platform abstraction are all found in the JVM. However, the fundamental difference is CLI's support for multiple languages. This is realized by defining an object oriented "common" language type system, called the Common Type System (CTS), which works across languages. Built on top of this common type system is a set of class libraries that can be cross-leveraged by any language that supports CLI. For example, once a String class is made available in one language, say C#, this class can be compiled to the common intermediate language, which can then be imported and used by any other language, such as the ones previously listed. This is a powerful capability since compiled code modules can now be shared among developers working in different languages. Even cross language class inheritance, for example, a C# class inheriting from a Visual Basic object, is possible.
The success of the .NET initiative requires wide adoption of its technology by the computing industry since Web Services require existence on, and interoperability between, heterogeneous systems. One way to accomplish wide proliferation is to open the technology to the industry. On the way, the technology is refined to reflect the ideas and requirements of other industry players. In June 2000, Microsoft, with sponsorship from Intel® and Hewlett-Packard*, submitted the C# language and the CLI specifications to the ECMA, an international standards organization, for its review and standards consideration. ECMA was chosen because of its "fast track" approval process status granted to it by the International Organization for Standardization (ISO), and ISO's history of standardization of computer languages such as ANSI C/C++. Since then, many other companies have embraced and joined this effort. Check http://software.intel.com/en-us/articles/ecma-c-and-common-language-infrastructure-standards to find the latest public draft ECMA documents on Intel's site.
The CLI specification as submitted to ECMA consists of the following:
- Partition I - Architecture. This document describes the overall architecture of CLI that makes the multi-language support possible. It discusses the common type system, metadata, and the restrictions on languages that make their interoperability possible. It also describes the lifecycle of objects within the Virtual Execution System.
- Partition II - Metadata. This document defines the CIL metadata syntax and semantics, along with its layout in memory and physical files.
- Partition III - Common Intermediate Language. This document describes the semantics, behavior, and binary format of the CIL instruction set and how types are represented.
- Partition IV - Profiles and Libraries. This document specifies the libraries that should be supported by a conforming implementation of the CLI. It also factors these libraries into profiles targeting different resource constraint systems. In version 1 of the submitted specification, only two profiles were delineated: the Kernel profile and the Compact profile. A companion document to this partition is a set of XML-formatted files that provide details of each class, value type, and interface in the libraries. These XML files can be processed to extract the class library information for different usages such as easy browsing.
- Partition V - Annexes. This document covers miscellaneous topics such as a number of sample programs written in CIL, compiler relevant design details, as well as general programming guidelines for cross-language APIs.
While partitions II and III are most relevant to compiler and tools authors, partition IV is most pertinent to application developers. This article provides a more detailed discussion of the class libraries described in partition IV.
The standardization process is a fairly lengthy one, but that is typical of all standards efforts. The C# and CLI specifications as of today are fairly complete and are expected to be ratified by the ECMA General Assembly in December 2001. Once ratified, they will be submitted to ISO in January 2002 for its review. With ECMA's "fast-track" process status through ISO, it is expected that the C# and CLI specifications will be ratified by ISO in September or October 2002, giving them the same status as the C/C++ programming languages, assuming everything goes according to plan.
After version 1 is ratified in ISO, and if there is industry interest, ECMA may begin a version 2 standardization effort. One area that will get a great deal of attention in version 2 is the class libraries specification. The process will be evolutionary, with new classes and class libraries added. Currently, .NET has over 4200 classes in its library collection. Only about 700 of them have been submitted to ECMA and only 288 o ut of the 700 were included in the current version 1 of the specification. A natural continuation path for the standard is to fold the rest of the 700 classes into version 2, and determine additional classes to standardize that will add value to the version 1 classes.
The CLI will have a place in mobile platforms, as well. The Compact profile, which includes most of the 288 classes submitted to ECMA, can fit in small footprint mobile devices such as PDAs and smart phones. Yet it includes powerful functionality such as Networking, simple XML, and lightweight Reflection, in addition to the base classes that include Security. These constitute a solid base that can enable Web Services in mobile devices. In the near future, the Compact profile may find its place in the mobile arena as Classmark 4 in the Mobile Execution Environment (MExE) specification that is driven by the Third Generation Partnership Project (3GPP).
Traditionally, libraries that implemented core functions on a given platform always accompanied computer language specifications. For example, the C* standard library was a companion to the C and C++ standard languages. The CLI class libraries are an integral part of the CLI framework and are made available to developers from any CLI-conformant language. Of course, the CLI specification calls for modern age class libraries that meet the expectations of today's Web-enabled applications.
Within the CLI class libraries lies a distinction between Microsoft's .NET and the ECMA CLI. What was submitted for ECMA's standardization is a subset of the Microsoft .NET libraries, as depicted in the following diagram. With that said, we can move on to describing only the ECMA CLI libraries.
The framework relies on Namespaces to organize classes. Much as a directory file structure is a physical container of files, namespaces are logical containers for classes and interfaces. The root namespace in CLI is System. All classes within the framework are contained within the System namespace. Base value types such as Int32, Boolean, and Char are organized under the System namespace. The root class that all value types and classes stem from is System.Object. System.Object provides low-level functionality to all members in the hierarchy.
Profiles are constructs created for the purpose of standard conformance and compliance. At a minimum, a CLI-compliant implementation must provide the classes in the Kernel profile. While the implementations of some classes in the Kernel are tied to the operating system or runtime platform, they offer developers a layer of abstraction that makes their application code platform independent. Let's take, for example, file IO or Console operations. Since the classes in the Kernel profile abstract these operations, an application can make use of them without being tied to the platform. The application code can then be "copied" to any operating system that supports the CLI and would be expected to work, thus fulfilling the promise of "write once and run everywhere."
The Compact profile includes a modest, yet powerful, set of classes that enable the development of modern Web applications and services. In addition to the Kernel profile specified classes, the Compact profile includes networking, XML, and Reflection classes. With the Compact profile, it is, for example, fairly straightforward to implement the Simple Object Access Protocol (SOAP) that can enable Web Services. This functionality is a key enabler for cross platform communication and interoperability.
As of yet, none of the Graphical User Interface (GUI) classes found in .NET are included in the current ECMA submission. The reason lies in the fact that GUI elements tend to follow the platform look and feel and/or capabilities. Additionally, the standards body wanted to focus on the underlying core implementation of CLI first.
The extended numeric and extended array libraries are not part of any profile, although they can be supplied by any CLI implementation, depending on the platform capabilities and needs.
An implementation can claim a given profile conformance if it implements all of the profile's mandatory requirements. An implementation may include additional functionality as long as it does not prevent proper operation of code that relies solely on the conformant profile. For example, an implementation may provide additional classes, new methods or interfaces on existing standardized classes and namespaces. However, it shall not add methods or properties to interface classes in the standard.
Some critics may look at the CLI initiative and discount its cross-platform promise because it is available as of this writing only on Microsoft Windows* platforms. Evidence so far indicates that cross-platform availability of CLI is inevitable. Many open source projects have surfaced since the ECMA standardization effort began. Additionally, Microsoft announced its plans to release a shared source implementation of the CLI framework, thus making it possible for projects to learn from Microsoft's experiences. Implementations on Linux by projects like Ximian's Mono*, Portable.NET*, and DotGNU* are underway.
The platforms most likely to benefit from the CLI architecture will be the mobile ones. The variety of hardware and operating systems found in mobile devices begs the need for a cross-platform execution framework. Thus far, this need has been answered only by Sun's Java* 2 Platform, Micro Edition (J2ME*). It is only a matter of time before CLI's Compact profile catches up and offers a truly open alternative to Java solutions.
The ECMA CLI specification gives developers a blueprint for the framework. Implementing this blueprint on a given platform is not a trivial task. The good news is that the majority of the code that makes up the framework is platform and operating system independent. By a dopting some simple design disciplines, developers can allow their implementations to be reused on different platforms with minimal effort. To discuss this point in more detail, let's delve into CLI's Base Class Library (BCL) within the System namespace.
The BCL contains about 147 classes that deal with value types, exceptions, string manipulations, collections, threading, security, globalization, and IO. A very small portion of the implementation must contain platform-specific code, while the vast majority can be generically developed for any platform. If the platform-specific code is pulled into a platform abstraction layer (PAL) that can be called from the generic code, then porting to new platforms becomes a fairly simple task. The porting becomes confined within the platform abstraction layer classes. The following is an example written in C#. (This example is extracted from Intel's Open CLI Library (OCL) project. OCL is part of the SourceForge* distributed Computing Foundry and can be downloaded from http://sourceforge.net/projects/ocl*.)
Within System.IO.Path class is a method that returns the path information of a temporary directory in the file system. This information is operating system specific. The implementation of this method can be abstracted as follows:
It is good practice to abstract the operating system through an Interface contract, thus requiring its implementation to be provided by all supported operating systems. The following IOperatingSystem interface illustrates this:
The concrete instantiation of the target platform object can be done through the following Platform class. This example shows the implementation under the Windows operating system. If the code were to be ported to Linux, then this class would create an equivalent Linux object.
The entire platform porting effort can then be confined to the following platform dependent class. This example shows the implementation under the Windows operating system. If the code were to be ported to Linux, then this class would be replaced with its Linux equivalent implementation.
As the example code demonstrates, CLI class libraries and framework implementers can make their code easily portable to many platforms. Keep in mind the power of the Common Intermediate Language. The platform-independent generic code, which can be written in C# or any other language for that matter, when compiled into CIL can be reused by any CLI-compliant language and platform. It is merely a matter of copying the generic code assembly file to the new platform to make things work.
The computing industry now has a new, appealing, compelling, and open framewo rk to work with. This framework bridges the boundaries between many computer languages and promises a unified cross-platform managed execution environment. The CLI framework is aimed at accelerating the next generation of distributed computing by providing the building blocks for the service-oriented architecture. The CLI framework is currently traveling on a standardization journey that will put it in the hands of many platform and language vendors. When ECMA's standardization work is completed, Microsoft will not own the CLI framework; it will have its own implementation of the framework. Other companies will most likely create their own implementations on non-Windows platforms. All companies will then compete on the merits of the services they provide on top of the standardized framework.
Although the CLI framework encompasses multiple programming languages, C# will always have a special place in the heart of the CLI framework, as it was designed from the ground-up to utilize the power of the framework.
Finally, the ECMA standardization efforts have made great progress so far. It is very likely that further standardization releases will follow.
For more complete information about compiler optimizations, see our Optimization Notice.
