Why COM?

COM is a binary standard for object interaction. But what does this statement mean? What's so important about a binary standard?

The fundamental goal of COM is to enable you to create applications that are assembled from prebuilt parts—that is, components. For example, an order entry application might use a data entry grid component to make entering the ordered items easier. Another component could look up a customer's city and state based on the zip code entered. Yet another component could compute sales tax on the order. To make this type of component-based application a reality, several technical challenges must be met (in addition to overcoming the "not invented here" syndrome and other social challenges).

The first challenge is to provide a standard way to locate components and create objects using those components. Otherwise, the overhead of learning how to use every component and coding the logic to locate the components and create objects presents a barrier to reusing prebuilt code. In conjunction with the standard mechanisms, there must be a way to uniquely identify components that are created independently by different vendors, to prevent scenarios in which an application developer asks for one type of object and gets a completely different type. Component developers must be able to generate unique identifiers for their components and provide those components to others without going through any centralized authority.

The second challenge is to provide a standard way of interacting with objects. Again, if no standards exist, the overhead of learning how to use the objects creates a barrier to reuse. Ideally, this standard mechanism for object interaction would not care where an object was located—in the application's process, in another process on the application's machine, or on another machine altogether. Usually, interprocess and remote communications require a great deal of complex coding in the application. However, if there is a standard way to interact with objects, it should be possible to hide all this complexity from the application developer—and hopefully from the component developer as well.

Third, application developers must not have to worry about what programming language or tool was used to create the components they want to use. Otherwise, the component market becomes fragmented and the cost of identifying and purchasing components that will work in a certain environment is too high. True language independence is a complex challenge for an object model. Everything about the object—memory allocation, method names, parameter types, calling conventions, and so on—must be defined in such a way that the object can be created by code written in one language and used by code written in another.

Finally, it must be possible to create new versions of applications and components. This requirement sounds trivial until you remember that the applications and components may be built at different times and that multiple applications running on a given machine might be using the same component. It must be possible to upgrade a component in such a way that it will continue to work with existing applications. This upgrade might involve fixing problems in existing features of the component or adding new functionality. In either case, existing applications must not break because a component was updated.

The binary standard for object interaction helps COM meet all of these requirements. COM is part specification, part implementation. The specification defines how to call objects in a language-independent and location-independent manner as well as how to locate and identify components and create objects. The implementation provides system services that do the actual work of locating components and loading them into memory, performing interprocess and remote communications, and so on.