COM Aggregation   «Prev  Next»
Lesson 6Aggregation guidelines
ObjectiveUnderstand why aggregation guidelines are needed.

COM Aggregation Guidelines

Aggregation is a composition of COM objects. One or more inner or aggregated objects is combined with an outer COM object in such a way that the outer COM object appears to implement all the interfaces in the inner COM objects, as well as its own interfaces. A COM client interacts with an aggregation as if one COM object, the outer COM object, was implementing all the interfaces. The inner COM objects are not visible to the client.
To implement aggregation, we have to answer two questions:
  1. How can aggregated (inner) COM objects work with the outer COM object to support interface navigation?
  2. How can aggregated (inner) COM objects work with the outer COM object to support lifetime management?
The implementation of both the outer and the aggregated objects must support interface navigation and reference counting across multiple COM objects in such a way that they appear to be one COM object. Supporting these requirements means that, unlike reusing inner objects via containment/delegation, inner COM objects that are part of an aggregation are aware that they are being aggregated and actively participate by working with the outer COM object. COM provides a set of implementation guidelines to support aggregation. These can be broken into inner object, outer object, and information exchange guidelines. We will study these guidelines in the few lessons.

Conflict between Aggregation and Interface Negotiation

It has been concluded that the conflict between aggregation and interface negotiation asserted by Sullivan is based on the specific definition of the reachability property and rule that is provided by them. It turns out that the Reachability property and rule are not parts of the original COM specification. COM specification does not have anything specific on component identity at run time. So, the notion of compromising an inner component’s identity is not relevant. COM aggregation cannot be used to implement mediator-based architecture, since this architecture may require access to an inner component's hidden interface. It has been shown that, if symmetry holds, transitivity and backward transitivity are equivalent. Hence, the transitivity of interface negotiation can be illustrated using an example that shows the backward transitivity of QueryInterface. The proof of most of the theorems, which are expressed using the formal model devised by Sullivan uses the premise of a legal component. This premise is not part of the original COM specification.