An insight into Code Reusability and COM Interoperability : Part I

Code reusability is the art of using existing code to achieve better productivity and ease of maintenance. The concept of reusability is not new. Its existence has been evident since the evolution of mankind.

Code reusability is the art of using existing code to achieve better productivity and ease of maintenance. The concept of reusability is not new. Its existence has been evident since the evolution of mankind. Most of our daily activities are a continuation of unfinished process and may not necessarily be a new process. We never try to reinvent a "wheel", however we  try for effective ways of using the wheel. This means that we are reusing the original ideas and continuously on look out for refining them. The question is why one should repeatedly discuss about code reusability when addressed by so many across the globe on numerous occasions. My feeling is that code reusability is a continuous and on going process. With new technologies emerging each day, we are nearing a day when we see true code reusability. In this article, I will try to address the new look given to code reusability and COM interoperability in Microsoft.NET technology and how if differs from Microsoft's previous technologies. This is the part I one of the two series article

  • What defines code reusability Usage across different programming languages  
  • Usage across different systems, devices and host environments
  • Integration and extensibility for present and future models  

Usage across different programming languages

Each programming language has its own power and potential. Most of them have evolved over a period of time and continues to evolve. Each of them has been invented with a specific purpose. Java for code portability across different platforms, FOTRAN for scientific calculations, PERL for string manipulations, COBOL for mainframes, C & C++ for embedded programming, C# for ease of component development, JavaScript/JScript for Internet Browsers and so on. Over a period of time, most organisations/companies would like to increase the productivity, whereas developers would like to enhance their logical skills and end users would like to see a better quality of service.  

In order to increase the productivity, an organization has to utilise the developer's skills effectively without repeat of work among developers working on different projects using different programming languages meant for specific purpose.  Take for instance, the logic for implementing searching and sorting algorithms doesn't differ across programming languages, however they differ syntactically.  

In the past neither the organisations nor developers visualized the need for true code reusability across different programming languages. However, the ice was broken long back in 1995 with the introduction of CORBA and COM technologies to address the cross language issue. Hence the idea of language integration didn't creep into the minds of developers at Microsoft all of a sudden. COM technology is a clear indication of their commitment to cross language interoperability. They released this wonderful technology while other existing technologies were taking birth.  

Using COM one can develop components using any language as long as one confirms to COM specification. COM requires binary standard to be followed in order to call the Components written in other languages. You can design very complex networks using COM effectively. It provides us location transparency, which was one of the main reasons behind the success of billion-dollar COM market. However, the problem posed by COM with respect to code reusability is that, it does not permit one to inherit the code written in one language into another. Hence the COM technology doesn't advocate the concept of true code reusability.  

True code reusability proposes for the code written in one language to be used in another. It means, one should be able to inherit the code written in one language into another and override a method and then extend the scope of the functionality
if necessary. 

Microsoft has worked hard to make this concept work, taking into consideration the views of many compiler designers, researchers, organisations and of course their own in-house feedback across the world. Many organisations are working hard to bring this dream idea to reality. As such there are 17 languages that support .NET platform and is still flexible enough to accommodate other programming languages in the future.  

The above diagram depicts how languages under .NET can be seamlessly integrated within a project.

Case Study

Consider an organisation having 100 developers.


  • Developers have to working on 5 different projects using different technologies. 
  • 20 developers for each project 
  • All are working on same domain - Banking sector 
  • They have different range of skill sets 
  • There is a technology, which permits code written in one language to be used in another language. (.NET Technology)


The following are the projects and their split up according to technology  

Project 1 - A web based solution for banking sector using Java technologies 
Project 2 - A web based solution for banking sector using MS Technologies 
Project 3 - A client server solution for banking sector using C and C++ 
Project 4 - A mainframe solution for banking sector using IBM technologies 
Project 5 - A CGI solution for banking sector using different programming languages

Traditional Way

When it comes to working on the above-mentioned projects, all the developers are working only on the same domain - Banking Sector. However, one has to allocate developers exclusively for each project pretty well knowing that the logic applied to accomplish these projects is more less the same.  


  • More or less the same work by developers across the same organisation working on different projects
  • Ineffective use of resources, time and energy
  • Less scope for the developer to enhance logical skills  

.NET Way

  • The code written for Project 1 could be used in project 2 and so on.
  • Accomplishing the same working maybe with 30 - 40 developers.  


  • Developers gets more time on hand to concentrate on the business logic
  • Developer can use the language one best knows to deliver a specific solution
  • Lesser number of developers
  • Advocates for true code reusability across multiple different programming languages

As the complexity of an organization and project allotment grows the computations also change. I feel that .NET Technology gives us definite power to treat languages alike and still exploit the best of language specific features. Ultimately, .NET technology brings better productivity for organizations, gives ample time for developers to concentrate on logic rather than integration issues and giving desired results to the end users.

Most of companies/organizations have invested substantial amount of money, resources and time in building so many applications using many different programming languages over the years. I throw a word of caution for all such organization while they plan to migrate to .NET technology. I am not going to talk all the goodness that .NET brings to an organization but at the same time address some of the issues concerned with migration.

Code written using COM technology
Microsoft has provided tools to ensure both forward and backward compatibility of COM components. When you convert your existing COM code base to .NET this runs under un-managed environment. However, if you target your code to run under the managed environment of .NET and exploit the features of CLR, you need to make changes to existing API and use corresponding Base class libraries of .NET, which requires considerable investment of time, money and resources.  

Code written using other languages and technologies
Since COBOL and other similar languages were never meant to develop COM there will be problems converting existing code base written using those languages to .NET.

Developers have to learn the Base Class Libraries of .NET and modify the existing code accordingly and then compile the modified code using CLR targeted compiler.  

So, I leave it open to the organisations/companies to think about when, where and how to start using this elegant technology. There are many tradeoffs involved. To know more about cross languages capabilities of .NET you can read my article titled " IL "The Language of CLR" - A Platform for Cross-Language".

Usage across different systems, devices and host environments

Organisations/Companies have spread across different geographical locations. The need for organisation/companies to communicate with each other has grown more than ever. As such, most the systems are heterogeneous in nature making the integration/using components across these systems difficult. This requires us to have a loosely coupled model that will have greater flexibility in both integrating and using components in distributed environment across internet/intranet. Put it simply what we are trying to do is use the functionality of the code across different heterogeneous systems. Let us first see the limitations of current models existing in the market.

The problem statement

Users are unable to integrate the data across different systems/devices at a desired location. We are unable to use the functionality imparted by code written at another location into our system effectively. This means that we have to re-invest time, resources and money to get the same desired functionality at our end. Let us try and understand this issue in more elaborate way. 

Limited interaction with computers 
The way we interact with computer is limited to either keyboard /mouse etc and not beyond that.

Localized user information
The preferences we set on a machine / application over a network, is a local phenomenon. Though, we will be able to login from different machine, we won't be able to restore the preferences set on the other machine.

Same user, same data across different applications
Different applications across Internet request for more or less same type of data. (Registering for an e-mail account on different server would ask more or less the same set of information etc.)

Difficulties in integrating data across different devices/systems
We receive data from various sources everyday. We are facing problems in integrating the data meant for one device/system to another.

Web site are unable to function in a more meaningful way
Web sites are unable to function in a more meaningful way. In other words web sites are unable to consume information among them selves to produce more meaningful experience.

Need for yet another technology
All the above scenarios address what is called as "Distributed Computing". There are various distributed technologies existing in the market by different vendors. 

S.NO Vendor Technology
1. Microsoft DCOM
2. Object Management Group CORBA
3. Sun Micro Systems RMI

All these systems have their own advantages and disadvantages. They all work very well with in the given environment. The problems arise while integrating with different heterogeneous systems. All these systems break on larger heterogeneous networks because they rely on tightly coupled architecture. If the implementation at one side is altered, the other side suffers. 

The limitations of the above technologies are listed below. All of them either require homogeneous environment or tightly coupled interface.  

S.NO Technology Limitation
1. DCOM limited acceptability other than Windows community.
2. RMI Language specific
3. CORBA Suffers vendor non - interoperability

Ideally speaking there should be a distributed technology that is loosely coupled. This means that you can change the implementation at either end of a connection and the application will still continue working. One should have message-based, asynchronous technology using standard protocols like HTTP, SMTP and XML.
The above diagram depicts how systems should be able to communicate with each other. Microsoft .NET technology encourages for loosely coupled distributed architecture. Hence takes a step closer towards better code reusability.   

Integration and extensibility for present and future models

Microsoft .NET relies heavily on open web standards such as XML, HTTP, SOAP and SMTP. All these are non-Microsoft proprietary standards.

  • Interoperability, integration, and application extensibility are very difficult and require high expertise, which only few companies/organisations can afford. Microsoft. NET's reliance on XML - eliminates the barriers between data exchange and integration across different systems and devices. 
  • Micorsoft.NET used open standards like SOAP, WSDL which themselves are pure implementation of open standard - XML.
  • Most of the organisations accept them to be as open standards and actively participated in the drafting of these standards. Though there are differences, the way they implement could be addressed in the days to come.  
  • The loosely coupled model of .NET framework and easy accommodation of new languages into .NET takes Microsoft way ahead as compared to its current competitors.

The best of .NET

Interoperability most of the times misunderstood to be as platform interoperability and it could be looked upon under the following categories. When a technology addresses all the three interoperability standards equally, only then it can be said to be as the best. 

Language Interoperability
Perhaps none else could match Microsoft with the release of .NET technology in this aspect. They have got a definite plus as far as language interoperability is concerned. With the release of .NET every language is a mere choice of programming rather than any thing else. Programming language is only for the programmer but not for the .NET CLR. Languages at present and in the future could be targeted to .NET CLR seamlessly.

Standards Interoperability
Microsoft heavily depends on open standards like HTTP, SMTP, SOAP and XML for global reach. These standards are more or less uniform across different technologies. Microsoft has contributed a great deal to the standardization of these protocols along with the industry leaders especially in the areas of SOAP and XML.

Platform Interoperability  
Architecturally speaking the code generated using .NET is platform neutral. Although there are efforts of porting .NET framework onto Linux, Java definitely has a plus in this area. Since, .NET is evolving, in near future I hope that there would be efforts to port it to different operating system not necessarily by the Microsoft. 


No technology is perfect. Over a period of time it needs to be evolved to address the developer community needs. I personally give credit to Microsoft's development team for taking up such a technical challenge and emerging successful. With the developments that are happening across the world, Corel Corporation is porting the .NET framework on Linux, MONO project is also trying to do the more or less the same independently. Different language vendors coming up with different compilers that target .NET. Research organisation doing their bit and the response that Microsoft got for its beta releases, I personally feel that there is lot to come from this technology than we have seen.   Certainly .NET has moved one step closer to the code reusability.

Stay tuned for the part 2 of this article, which deals with COM Interoperability in .NET.