Comparing the .NET Framework and IDL-Based Systems

It is an interesting exercise to compare the architecture of the .NET Framework with other distributed architectures that provide many of the same facilities. Both COM and CORBA, for example, address many of the same issues that the .NET Framework tackles. These architectures utilize an Interface Definition Language (IDL), which addresses many of the issues discussed earlier. But how does this interaction happen?

When developing a program with either COM or CORBA, a developer writes an IDL file that represents the interfaces provided or required by the server. The IDL provides the common type system and some built-in types, and it also permits the developer to define his or her own simple types and interfaces. At IDL compile time, the IDL compiler can generate and write metadata to a file. Clients can use this file, which is known as a type library in COM and an interface repository in CORBA, to discover the types and the interfaces they provide. The IDL compiler also generates proxy objects. These objects, which reside in the client and server processes, translate data types between machine architectures and translate between the different execution models of different programming languages.

If COM and CORBA already address these issues, then why would a developer use the .NET Framework? First, both COM and CORBA have some limitations. An IDL is a separate language that must be used in addition to the development language. Although both COM's and CORBA's IDLs are based on C/C++, this fact offers little help to a SmallTalk programmer. Second, the IDLs greatly restrict facilities such as method overloading, and neither provides a rich exception hierarchy.

Third, the metadata files produced by the IDL compilers are not necessarily embedded with the type's definition. This fact leads to any of the following situations:

• A developer may have access to a type (that is, its implementation file), but no metadata (that is, its type library or interface repository entries).

• A developer may have a type's metadata but not the type (the reverse of the previous case).

• A developer may have a type and inconsistent metadata ”in other words, the metadata refers to a different version of the type. This situation occurs because an IDL compiler generates the metadata but a language compiler generates the type.

Finally, IDLs deal in interfaces, not types ”hence their name . A developer could potentially find an interface that describes a number of methods that perform tasks that the developer wishes to provide and gain access to a type that implements this interface. The developer may then wish to add a single method to this interface. Unfortunately, he or she may not be able to reuse the type that implements the first interface and just add the implementation for the new method. In the .NET Framework, if a developer finds a type that implements all the methods required, he or she can subtype from that type, subject to certain constraints. The developer can then add, or even override, only those methods for which different behavior is required, regardless of the language in which either type is written.