Establish Reuse Terminology in COM

So far, we have determined that:

1. Software components integrate at the binary level.
2. 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:

1. We have a COM client called COMCli.
2. We have a COM object, used by COMCli, called OuterCOMObj.
3. We also have a COM object called InnerCOMObj that is reused by OuterCOMObj.

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.

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.

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.