Software components integrate at the binary level.
Software component reuse is based on object composition.
Having surveyed the difference between source-level reuse and integration as used in C++, and binary-level integration and reuse as used by software components, let's move on to COM's reuse mechanisms.
For our study of COM's reuse mechanisms. let's set up a scenario and some terminology:
We have a COM client called COMCli.
We have a COM object, used by COMCli, called OuterCOMObj.
We also have a COM object called InnerCOMObj that is reused by OuterCOMObj.
Global Unique Identification
Since the reusing of the components is at run time (i.e., a component is a run
time reuse object) and a reuse object may come from various developers around the
globe, a scheme that has a capability to provide strong identification is needed.
Microsoft has chosen a 128-bit identification number for components and interfaces.
Role of the Operating System
The COM scheme needs operating system support for it to be effective. The operating system keeps the necessary information about the available components. Such information includes container files, the path of container files, and the identification numbers. All components must be registered with the operating system before they are made available to be used by a client.
The following illustration depicts the relationship between COM client COMCli and both COM objects, OuterCOMObj and InnerCOMObj.
In our discussions, OuterCOMObj will be called the "outer COM object" and InnerCOMObj will be called the "inner COM object".
For now, do not worry about the COM servers that contain each object. Also, do not be misled by the names of each object. The client is not aware that OuterCOMObj is reusing InnerCOMObj.
COM supports two basic reuse mechanisms: containment/delegation and aggregation. We will discuss containment/delegation throughout the remainder of this module. We will discuss aggregation in the next module.