An insight into Code Reusability and COM Interoperability - Part 2

Introduction

We have mushrooms of network systems running across the globe based on many proprietary protocols. In order to integrate these systems to communicate with each other in a more meaningful way, developers or organizations have to face an uphill task.

Gone were the days when only few elite individuals used the term "Internet/Intranet". The need for understanding the Internet's potential and limitations has grown more than ever. IT industry is constantly maturing towards delivering much better solutions than in the past. In order to see the World, as a true "Global Village" there is a need for every one in the industry to follow common minimum uniform standards.

In the past there were only few standard protocols like HTTP and FTP for Internet. Whereas there have been many proprietary protocols adopted by different organizations, which best work in their local area networks. The increasing need to communicate with different systems to share information has made every corporate to think about implementing open standards.

When Unix operating system was developed long back in 1970's or the other operating systems till very recently, the system designers never had thought of Internet so seriously. In order to support the emerging Internet standards, each operating system vendor constantly releases a series of add-ons in the form of Web Servers, etc, the result of which is that we are unable to get direct support from the operating systems itself, upon which the web servers run.

Non MS Platforms

The key factor missing in most Non MS Platforms is that they are not built with Internet in mind like that of Windows 2000 Server which is built specially keeping internet as the basis. Most of them don't strongly support COM/DCOM, though there have been alternative solutions to overcome this.

MS Platforms

We have many platforms and technologies introduced by Microsoft in the past. The most notable platforms are DOS, Windows 95, Windows 98, Window NT, Windows ME and now Windows 2000 and Windows XP. On the technology front we have ActiveX, COM/DCOM, COM+ etc. When we observe very closely, what we see is that on all these platforms, we have been using more or less the same set of API. Microsoft kept on adding more API's with each of its new platform releases, but nothing that fundamentally changed the way we program. Though they have MFC which has the object-oriented functionality, it just interfaces the earlier C code base that was used to develop Windows3.1 etc.

The Emergence of COM

In order to understand how COM had taken its birth let us have a look at earlier theories exiting in the market prior to its birth. The following table summarizes various technologies prior to COM and after COM.

S.NO	Technology
1	Library Functions
2	DLL's
3	OLE
4	VBX/OCX
5	COM
6	COM+
7	.NET

All programming languages but for some of modern languages (C# doesn't have built-in library functions) have built-in library functions to carry out commonly used set of functionality. Libraries give us tailor made solutions for many tasks. This is what is called as static linking of the libraries. This was more prominently seen in languages like C/C++, Pascal and COBOL etc. Later on, there was much focus on linking these libraries at runtime so as to achieve better memory and performance results. These are what are called as DLL's (Dynamic Link Libraries). One serious limitation that DLL face is that it is very language specific. Later, there were efforts to link and embed the objects in other applications to reuse the functionality.

Microsoft implemented this concept so powerfully with Microsoft Office documents of different types (e.g., Word, Excel, PowerPoint) to be linked together and embedded within each other to create a integrated set of documents. Microsoft named its approach as Object Linking and Embedding (OLE) which ruled the market for quite some time.

If we look at OLE, it is nothing but inter-object communications and that is possible only through Interfaces. Some examples of OLE are Linking, Embedding and Drag-and-Drop etc. These features we find so well integrated within Microsoft applications like VB and VC.

The later part of the code reusability came with the VBX/OCX controls, which enabled the drag and drop functionality. The key idea behind the VBX's was to enable third party developers to write add-on applications that integrate them with VB run time environment. VBX controls were generalized for different environments and Microsoft called it as OCX controls. It is with the introduction of VBX/OCX controls that Microsoft had brought the idea of binary reusability to the forefront.

COM is a major leap toward the code reusability. More than code reusability, COM promotes what we call "functionality reuse". It's almost language neutral. The next of COM is what is known as COM+ Services. On Windows NT 4.0 we used to have MTS (Microsoft Transaction Server) to provide transactional support. We need to specially program our applications for MTS. Whereas in Windows 2000 Servers, this capability is built into the operating systems and hence provided by the COM environment, which Microsoft calls as COM+ Services. With COM+, we needn't have to specially program anything for acquiring transactional capabilities for a given application.

The Drawbacks of COM

Component design is a billion-dollar market. There are many companies, which relied extensively on this technology and gained huge profits and other benefits. In spite of its success story, COM has certain limitations. The following points will explain the areas where COM has limitations.

No True Code Reusability - COM has limited support for true code reusability. Under the COM technology we are able to use the functionality but not the code reuse. This means that one can't inherit the code written for one DLL into another, override it and extend the functionality, whereas, when required, one will be able to use the functionality written in one DLL to another.

Global Access - When we install a COM on a machine, the same component can be used by all the applications running on that machine. The registration of COM component leaves us with two things i.e., when we register a COM component, system makes an entry into the common shared location called Windows Registry and another entry anywhere on the disk. Making an entry at the common location has lead to many technical problems like versioning and maintenance and server restarts.

Complexity - COM relies extensively on different threading models. The efficiency of its working also, in most cases, is dependent on the threading model we use for designing the component. This leaves us with a big void, i.e. we have to know which operating system supports which threading models and how to ensure both backward and forward compatibility so that the component can be used across all platforms, without loss of efficiency.

Usage across different platforms - Theoretically, we can use any language to design a COM component. Practically, however, there are many problems in porting across different platforms. Let us say, one has developed a component using VB to use it in ASP applications. It works fine on almost all Windows platforms. But the problem creeps when we try to port ASP applications on other platforms. In most cases, one needs to rewrite the code using C++. This is exactly what happens when you try to use Chilli ASP to port ASP applications on Unix or other platforms.

Problems with Different MS Languages - Microsoft has many proprietary languages like VB, VC++ (Microsoft Foundations Classes) and VJ++ (Windows Foundation Classes). If you look at the API's used by these different developers, they differ to a great extent. There is no common uniform library to develop same sort of applications and, that to, unfortunately from the same vendor. This has put a lot of burden on programmers to learn all these types of API and integrate the applications.

Versioning Problems (DLL HELL) - The problem with COM components is version maintenance. Many times, the newer versions of COM component overwrite its earlier version. Yet, at times, this results in breakdown of earlier applications.

IIS Server Re-Starts - Whenever we register COM components to be used with in ASP applications we need to re-start the IIS server in order for the changes to take effect. This is one of the limitations, as we need to bring down the site each time we want a change to be brought into affect.

COM VS .NET Components

COM exposes standard Interfaces to communicate with other components. COM encapsulates the language specific details and implementation details thus shielding the code to be modified by the client. COM follows binary format as standard. As long as the components adhere to binary standard the component will be able to communicate with each other irrespective of the language used to develop the COM component.

A COM compatible component must support IUnKnown interface. This interface is responsible for reference counting of the component. If this reference count is "0" then COM deallocates memory automatically. When you compile a COM component, all the information about various methods and their parameters is stored in a 'Type Library'.

COM implements an algorithm, which is based on time and zone, which generates GUID (Globally Unique Identifier), which is a 128 bit unique ID.

.NET components are self-describing about the classes they implement and the information is stored in an internal segment knows as manifest. Apart from that, Metadata does the following functions like.

1. Describes and references the data types defined by the VOS type system.
2. Lay out instances of classes in memory.
3. Resolves method invocation
4. Solves Versioning Problem (DLL hell)

The following table summarizes the differences between COM and .NET
 

S.NO	COM .NET
1	Promotes Functionality Reuse. Advocates code-reuse.
2	Global access of components on a machine. No Global access
3	Registering of DLL's required No registration required
4	Registry information and DLL's are stored at two different locations (DLL Hell). Entire information required to identify version and others are stored at a single location (DLL Heaven).
5	Difficult to understand. Easy to understand.
6	Run under Unmanaged environment. Runs under Managed environment.
7	Server restarts required for ASP applications. No server restarts. Promotes side-by-side deployment of the applications.
8	Languages and Tools take priority while developing COM No priority for language or a tool under .NET
9	Strong affinity to Windows Operating Systems Independent of Operating System.
10	The success of COM to certain extent depends on the threading model used to design the COM, which varies from tool to tool. VB supports two threading models, whereas VC++ supports four threading models, etc. In .NET, the process is simplified and by default the .NET components under Windows 2000 server are Neutral threaded.

Necessity for interoperability between .NET and COM

.NET is definitely a great improvement as far as COM technology is considered. It brings us nearer to true code reusability. However, many organizations have invested substantially huge amounts in building COM components. COM has been there in the market for almost 7 years. And, the last decade saw a substantial growth of the IT industry in various segments, which means that there has been really so much of code packed in the form of components. So, it is almost impracticable for one to re-write the entire code into .NET components, however good they may be for designing more robust applications. Existing applications using COM components are already tested, and, if one were to shift to .NET components, this testing would have to be carried out again. So, there is a great need for interoperability between the COM and .NET components.

Managed Environment VS Unmanaged Environment

The code that runs under .NET Environment (CLR) is said to be managed code. It is so because the CLR takes care about automatic memory management of the code running under its supervision and also provides us with cross language capabilities.

The code that runs out of .NET Environment (CLR) is said to be unmanaged code. Such code is usually tied to a platform, and will not acquire the features such as automatic memory management, etc.

The good news is that the .NET Framework permits us to move between managed and unmanaged code.

Best of .NET

The following tables summarizes the best of .NET components

S.NO	Feature Justification
1	XCOPY deployment Unlike COM, .NET components can be copied to any part of the location and used independently of other versions of the same component. This avoids versioning problems that are arising due to entries that are made in Windows Registry. Deploying two versions of the same components sometimes is called as side-by-side deployment.
2	Platform Neutral .NET components are platform independent.
3	Unlike the binary standard, their lower common denomination is Intermediate Language. You can design the components using Intermediate Language itself. This is what facilitates cross-language capabilities of .NET Framework.

Tools for Interoperability between .NET and COM

Type Library Importer (TlbImp.exe) Converts the type definitions found within a COM type library into equivalent definition in managed Metadata format.

Type Library Exporter (TlbExp.exe) Uses a managed assembly as input, generates a type library containing COM definitions of the public types defined in that assembly.
Assembly Registration Tool (RegAsm.exe) Enables classic COM clients to call managed classes. RegAsm reads the Metadata within an assembly and then adds the necessary entries to the registry. So classic COM clients can create the managed classes transparently.

ActiveX Control Importer (aximp.exe) uses an ActiveX control's type library as input and generates a wrapper control that allows the ActiveX control to be hosted by Windows Forms.

A brief introduction on how to use different Tools

Converting existing COM Components to .NET

The tool used to covert the existing COM Components to .NET Components is TlbImp, which stands for Type Library Import. The following diagram describes what happens when a COM component is converted to .NET component and how it is called.

Example:

Assumptions:

There is an already existing COM Component called testcom.dll

In order to use the above component called testcom.dll, you need to first covert the testcom.dll to .NET aware component.

You can do so by issuing the following command at the command prompt:

TlbImp testcom.dll /out:testnetcom.dll

In order to use newly created .NET component, testnetcom.dll, you will have to reference this DLL during compilation.

Converting Existing ActiveX components to .NET

In order to use the existing ActiveX components in .NET, we need to use a tool called AxImp that stands for ActiveX import.

Example

Assumption:

There is already an existing .ocx file named testacitvex.ocx

In order to make this available in .NET, issue the following command at the command prompt.

Aximp testactivex.ocx

Note:

It creates two files, viz. testactivex.dl and Axtestactivex.dll

In order to use the above files in .NET applications, open visual studio, reference the Axtestactivex.dll and use the control just like any other ActiveX control.
Converting the .NET Components and using them in Traditional Applications

In order to convert the .NET components to traditional components, one should use a tool called RegAsm that stands for registry assembly. The following diagram explains what exactly happens when you would like to convert .NET component to COM.

Building a simple .NET component Using C#

using System;
class Test
{
public int testmethod()
{
return 5*5;
}
}

Note:

1. The application should not contain Main method
2. Save the file with firstcom.cs
3. Compile by issuing csc /t:library /out:firstcom.dll first.cs

Now your first component firstcom.dll is ready.

Using in Traditional Applications:

In order to make it available to traditional applications running on your machine, you should issue the following command:

RegAsm firstcom.dll

Note:

1. Once you have done that, in order to test it, open Visual Basic and refer to the firstcom.dll and write a simple application. 
2. By default, the components designed using C# on Windows NT4.0, are both threaded.
3. You might have also seen how simple it is to write Components using C#.
4. You also get direct support for setting Properties and Events at the language level itself.

Converting .NET ActiveX components to traditional components

In order to make .NET ActiveX components available to traditional applications, you need to use a tool called as TlbExp that stands for ActiveX Import.

Example:

Assumptions:

There is a exiting .NET ocx file named dotnetactivex.ocx.

Issue the following command to convert it to type library:

TlbExp dotnetactivex.ocx

Note:

It creates a file called as dotnetactivex.tlb that can be referenced by any traditional tools and used just like an ordinary ActiveX component.

Summary

1. .NET allows for both forward as well as backward compatibility of the components.
2. .NET advocates for true code re-usability.
3. .NET makes all programming languages equal.
4. .NET eliminates platform dependency.
5. .NET applications are independent of the machine architecture.
6. .NET looks like a promise for the future.