The Execution System Versus Other Component Models

The type and metadata systems share many similarities in the component architectures mentioned so far in this book. In general, because .NET was created after the development of the other architectures, it provides some evolutionary enhancements to their type and metadata systems. For example, COM, CORBA, and .NET all provide a set of primitive built-in types and allow developers to define their own value types and interface types. An evolutionary difference between .NET and these other component architectures is that the former supports the notion of classes that are available across languages for inheritance. The metadata systems also share many underlying concepts; for example, an evolutionary difference is developers' ability to extend the metadata system with custom attributes in a standardized manner. Nevertheless, the execution system arguably provides the most substantial differences between the different architectures.

COM is largely tied to the Windows family of operating systems. Although some attempts have been made to port COM to other operating systems, many facilities and services continue to be implemented in a very Windows-specific manner. For example, the Single Threaded Apartment (STA) model, which uses a message queue to serialize messages to STA-bound components , does not lend itself naturally to implementation on other platforms. Other concepts, such as the Registry, while not strictly incompatible with other operating systems, inherently lead to complications when trying to provide a seamless means to move components from one platform to another.

CORBA provides platform independence in a somewhat different manner. The OMG initially standardized the IDL, IDL-to-language mappings, and communication protocol ”General Inter-ORB Protocol (GIOP) and Internet Inter-ORB Protocol (IIOP) ”but left the execution environment as mainly an implementation detail. This choice allows IDL compilers to emit code, such as proxy objects and base classes, that are specific to a target language and a platform. A large amount of effort has recently gone into providing more interoperability within the CORBA execution environment, as evidenced by the replacement of the Basic Object Adapter (BOA) with the Portable Object Adapter (POA).

Effectively, many of the issues that COM and CORBA face relate to the generation of proxy objects and implementation code at IDL compile time. In the CORBA world, this often means, for example, that for every language and platform that wants to access a remote object, an IDL compiler is run to produce language- and platform-specific code for clients to bind against.

A variation on these execution models is the notion of a standard execution environment, such as those provided by virtual machines that have been in use since the 1960s and that became extremely popular in the 1990s with the introduction of the Java Virtual Machine (JVM). The initial reservation in adopting these execution environments focused on their poor performance at a time when their main advantages, such as code mobility, were not a high priority. Clearly, as hardware has increased in power and decreased in price and the use of distributed systems has grown, the balance has tilted in these environments' favor. The CLR favors supporting an abstract execution environment, one that is independent of a specific hardware platform. A clear difference between the CLR's execution environment and traditional virtual machines, however, is the fact that the CLR execution system was never designed to be interpreted. The CLR performs JIT compilation, or possibly compilation at install time, to maximize runtime performance. In fact, one can argue that this JIT compilation actually provides the most optimized code, as critical aspects of the execution environment ”such as system memory, available disk space, and the exact version of the CPU ”become known only at deployment or runtime.