Component Object Model Overview

Introduction

Component-based development using COM (Component Object Model) can help solve multiple development problems that an enterprise software project might have:

  • Interoperability - Even though software was developed by different companies, COM ensures that these software components can work together in an enterprise software application.

  • Versioning - When it is time to update one or more components of our software system, COM affords the luxury that other components of the same system will remain functional and will not break.

  • Implementation Independence - COM allows that components written in different languages can still communicate with each other in a software system.

But what is COM and how does it accomplish those goals? And how does COM allow companies to build software solutions that are cost-efficient and robust, while also being capable of being easily extended or re-used? First, let's look at what COM is and its guidelines.

COM and its underlying concepts

The Component Object Model (COM) is a component software architecture that allows software systems to be built from objects. These objects expose services that provide functionality to the user. For the objects to be able to do this, there must be a mechanism that allows the objects to connect and communicate with each other in a well-defined manner. This mechanism is supplied by COM. Now before we discuss COM's guidelines, we must define some concepts:

Objects

Objects are just real-world models of some piece of our software system. Each object is comprised of properties, methods, and events. The term object is synonymous with component.

Properties

A property is representation of some piece of data connected with an object. To illustrate via example, let's take some thing very concrete, a home stereo. Some example properties of a stereo would be the current volume level, the total number of speakers, the station it was currently set to, etc. Generally, when describing an object, most nouns used to describe the object is a property.

Methods

Where properties where nouns, methods are usually the verbs used to describe an object. To build upon the home stereo example, some verbs we would apply would be increase/decrease volume, change station, change band (am/fm). Now notice that an increase volume method would just increment the current volume label property.

Events

Events are almost identical to methods with the exception that they are called in response to some user input. An example of an event is when the stereo is turned off, you might have a PowerOff method that saves the current station, volume level, etc.

Interfaces

Interfaces are an abstraction of the set of properties, methods, and events that are provided by the object's data and functionality that implements that interface. An interface is what clients will interact with to use the COM object. The interface for our stereo example would the all the properties, methods, and events available for our home stereo.

Client Object

A consumer or user of an interface.

Server Object

A provider or supplier of an interface.

COM Guidelines

Now that you are armed with the key concepts, let talk about COM's guidelines:

  • Each object must define a base interface (Iunknown) in addition to any other interfaces the object(s) supports.

  • Each object and each interface must be "strongly typed". In other words, each object and interface must be able to be uniquely identified.

  • Each interface supplied by the object, once published or used, must not change. Any additional functionality must be implemented in a new interface.

Please note COM concerns itself only with objects and interfaces. No mention is made of platform or programming language. That is because COM is implementation-independent. As long as your objects and their associated interfaces comply with the COM standard, they can be implemented in any programming language that is capable of returning references to interfaces (C++, Visual Basic, Smalltalk, ADA, Java, etc.).

Iunknown

The standard interface exposes three methods: QueryInterface, AddRef, and Release. The first method is the key one to understand because it does two things: a) it gives the client a way to determine if the desired interface is supported and b) it returns a reference to the interface by which the client can access any of the functionality of that interface. AddRef and Release are simple reference counting methods. Once a client get a reference to an interface, it needs to increase the count of total client objects by one. When the client object is finished, it needs to decrease the count. If the count is nonzero, the object knows it needs to stay in memory. Otherwise, it can unload itself from memory.

Interfaces must not change

This is a key one to remember. Once you release a COM object, there definitely will be clients that will be designed to use one or more of the interfaces that object provides. Now if you change that interface, the client software will definitely be broken.

COM accommodates this situation by requiring that any new functionality needed be implemented in a new interface. Common practice is to create a new interface with the same function set as the old interface and just add the new functionality to the new interface. Existing clients can still use the old interface and new clients developed since the new interface was added can use the new interface.

Uniquely identifiable objects and interfaces

COM dictates that each object and interface be uniquely identified. This is accomplished by assigning a globally unique identifier (GUID) to each object and interface. This convention removes any chances of 'name collision' by using GUIDs to identify objects and interfaces instead of human-readable names. It would be virtually impossible for guarantee uniqueness using human-readable names (ex: MyHomeStereo)

COM Benefits

So, how does COM answer our problems mentioned above?

  • Interoperability - By virtue of the QueryInterface capability, client objects have the capability to discover which interfaces a server object offers.

  • Versioning - COM alleviates this by the interface contract; as long as server objects continue to support previous interfaces, new functionality in an object won't break existing client objects.

  • Implementation independence - The COM standard only specifies how objects communicate with other; it makes no requirements on how functionality is implemented behind the interface.

So what benefits does COM provide to our software project:

  • COM supports code re-use between diverse platforms. COM objects of a certain architecture can be used by any language that supports structures to interface with COM server objects.

  • COM reduces code complexity. Each COM object can be referenced by many COM clients. This leads to high scalability of COM-based software systems.

  • COM provides extensibility of current software systems. New functionality added to COM objects won't break existing interfaces and won't impact existing client code.

Now that we have a level of understanding of COM, its guidelines, and its benefits, let's look at an example of a COM object: a calculator object.

An example: A COM Calculator object

For the sake of argument, let's say we have multiple applications that need calculations performed for them. If we need consistent results across multiple applications, we will require a uniform routine to perform the calculations. Otherwise, development time (and money) would be spent on multiple efforts to implement different pieces of software that perform the same calculations with inconsistent results.

Now, if we had a COM object that provides the calculator functionality to multiple clients, that would be ideal. Now what would that object's interface look like? Here are the properties and methods for an annual percentage rate calculator:

Properties

  • Interest rate

  • Length of loan (in years)

  • Loan Amount

  • APR

Methods

  • Calculate

This example is a simple one considering the object has three properties and one method. But if you consider an application used by a mortgage broker or financial institution (bank, credit union, etc.), there many different calculations they will need to be performed. And if we needed more precision for APR or if we needed to include more variables in one of our calculations, we just expose an additional interface that has the new method that includes the additional variables to be used in the calculation.

The result will be that you will have a COM object with many interfaces that can support multiple clients, and that can be easily re-used and/or extended.

Summary

The component object model is a component software architecture that can solve several problems and also provide multiple benefits to most software projects. As long as a project's software objects follow COM's guidelines, a software system can be easily-re-used and extended, while retaining its robustness and cost-efficiency.