ActiveX and COM -- Part I

The difficulty of reusing binary files at the application level has been around for years. Once source code has been turned into a binary executable, it does not have the capability to import and use the binary files produced by another application as part of its own machine code. A number might represent a data item, a procedure, or an internal value and the containing program has no way of knowing which it contains.

History

The developers of the Windows 3 operating system had a problem and developed a solution, the dynamic link library (DLL).
The DLL is an executable file that can never run on its own. The operating system loads the DLL into memory when the actual application requests it. Then the requesting application uses the code from the DLL as if it was included in its own binary file without knowing how or what language in which the DLL was written. The DLL provides a list of exported functions that developers can call with a simple application programming interface (API) that provides no hint as to how the functionality is implemented internally. This was the binary compatibility that was sought after for so long, and DLLs can be thought of as black boxes for reusable code.

DLLs were the first components in the software world. They were the first step to stop the NIH (not-invented here) syndrome -- and attitude of developers that any code that they did not personally write was inferior. This tendency in programmers to distrust the work of others continues to be the main obstacle to adoption of any standard in reusable code. The DLLs isolate the developers at the binary level, making them cost-effective black boxes.

Improvements

Although DLLS solved the reinventing the wheel and binary incompatibility problems, DLLs have problems of their own. Developers have to hard code their locations or make sure they are in the WINDOWS/SYSTEM directory. Memory allocation in DLLs is tracked separately from that of the calling application. In addition, there is no functionality to tell applications which DLL version is present, which can cause inconsistent behavior when different programs try to use different versions of the same DLL. Typically, this problem manifests itself when different applications from different vendors buy a DLL from a third party and distribute it. An application can still use an older version of the DLL, even when a new application is installed, "breaking" the application because it was expecting functions that no longer exist.

The component object model (COM) was created to fix the problem of "broken" applications. COM is the programming technology of today and the future because it provides the features that are required in today’s Web-enabled computing environments. It provides implementation independence that is inherited from the DLL. Developers can write COM servers and clients in any development environment, from a simple text compiler for C++ to rapid application development (RAD) tools, such as Visual Basic or Delphi. Any COM application can use or be used by any other COM application regardless of development environment. COM also provides a more usable hierarchical model of functionality. COM is totally independent of location because objects are registered in the operating system with their location. COM also makes distribution and updating simple because developers can update pieces of your application without completely recompiling the whole application -- the application just updates the objects.

Many Flavors

COM began as object linking and embedding (OLE) in which one application could display another data without explicitly opening that application. With Windows 3.1, OLE 2 produced the compound document that embedded information from any number of supporting applications so the developer could edit the data directly within any of the contributing applications automatically. Automation followed (discussion to follow). This technology provided editing directly inside the calling application in addition to some useful features, such as the ability to access COM services from a non-C++ development environment and the creation of COM-based components that were not the compound documents of OLE. These components were OCXs, now called ActiveX controls but still use the same OCX type. The ActiveX control works with Visual C++ and Visual Basic, National Instruments LabVIEW, and even applications such as Microsoft Excel and Word. ActiveX is now the term used to describe technologies built on COM -- ActiveX documents, ActiveX automation, and even OLE for process control (OPC) falls under ActiveX. Now with DCOM, you can distribute your application across a network, such as your company intranet without extra code writing. And finally COM+, in the Windows 2000 OS, is the latest incarnation of COM that adds COM functionality into the operating system and provides advanced functionality, such as the Microsoft Transaction Server (MTS) and Dynamic HTML (DHTML) and other Web services.

Why COM?

Developers have been exchanging code for years, even before there was Microsoft. However prior to COM and DLLs, giving away source code was the only way programmers had to exchange their code -- considering the time and resources involved, this is hardly a good idea. COM eliminates this setback and works so well that neither the client nor the server need to know anything about the other. As long as both follow the rules of COM, they can be written in different languages and combined together as if one developer had written both applications in the same environment.

How does this happen and what do we mean by the client and server? The client is defined by where the functionality of the server or object is needed. Thus the client calls the server to get the required functionality using the COM architecture. The server or object is defined by where the COM developer puts his/her work. COM servers can be either DLLs or EXEs. The server provides one or more objects for the client and also provides the relationship or hierarchy of the internal object functionality.


Figure 1 shows an example of interfaces and objects. There is an example of how the Dog interface can inherit from the Animal interface. There is also an example of how seemingly unrelated interfaces can be combined to create an object, the Guard Dog object. This is also an example of good object-oriented code design.

Clients view objects as black boxes that provide the functionality they require. Clients communicate with objects through interfaces, and objects, or servers, can handle more than one interface. COM interfaces are a set of related methods or functions. An interface does not describe the implementation underneath, giving the developer the option of changing how something is accomplished without having to change the whole application. Interfaces cannot be changed after they have been published. Because COM defines a standard for in memory layout of interfaces, the objects are compiler and language neutral, meaning objects can communicate without having to be written in the same language. Interfaces help with versioning and updating of objects, in that a developer can place the new functionality of an updated version in a new interface. Newer clients can query for the newer interface and use it if present, but still function with the older functionality.

Many environments provide some tools to make writing COM servers and clients easier, such as wrappers for accessing COM servers, wizards to create skeleton servers or controls, and tools to add interfaces and methods. National Instruments provides tools for creating servers and clients, some of which are Measurement Studio, LabVIEW, TestStand, Lookout, BridgeVIEW, and HiQ.

Conclusion

When dividing development up among different developers, software interoperability becomes an issue. The different developers might not have expertise in the same programming languages, or some languages may be better suited for creating certain parts of the application. Therefore, different components of the application must be able to communicate with one another even if written using different compilers. COM was created so that different components could communicate through a shared interface, even when written in different languages using different compilers. COM is currently the best way to have software componentization and interoperability inside the Windows environments.

Reader Comments | Submit a comment »

Excellent document answered to all of my ques
- Ashwini K. - Jun 8, 2005