COM Aggregation   «Prev  Next»
Lesson 3 Aggregation Review
Objective Review Aggregation

A Review of Aggregation in Microsoft's Component Object Model (COM)

I. COM Introduction

The Component Object Model (COM) is Microsoft's platform for component-based software engineering, which emphasizes the integration of distinct and potentially disparate software components. One of its central tenets is the ability to reuse and extend components without extensive code modification. Aggregation, a pivotal mechanism within COM, serves this exact purpose. This review endeavors to succinctly present the defining characteristics of COM aggregation.

II. Definitional Overview

Aggregation in COM refers to the ability of one object (typically termed the "outer" object) to use the interfaces of another object (the "inner" object) as though they were its own. This mechanism bestows upon the outer object the capabilities of the inner object, thereby facilitating a form of object-oriented inheritance without inheriting implementation.

III. Key Characteristics of COM Aggregation

  1. Seamless Interface Exposure: Through aggregation, an outer object can expose the interfaces of an inner object seamlessly. To any external client, the delineation between interfaces implemented natively by the outer object and those routed through the inner object is imperceptible./li>
  2. Unified Identity: Both the inner and outer objects share a single identity. This is primarily managed through the IUnknown interface, which is the primary channel for querying interfaces and managing object lifetimes. Any client holding a pointer to one of the object's interfaces essentially holds a reference to the unified identity of the aggregated object.
  3. Shared Reference Counting: One of the intricate aspects of COM is its reliance on reference counting for memory management. In the context of aggregation, both inner and outer objects share the same reference count. This ensures that the lifetime of the inner object is tied to that of the outer object.
  4. Selective Interface Exposure: The outer object retains control over which interfaces of the inner object it wishes to expose. This means that, while the inner object might implement multiple interfaces, the outer object can choose to reveal only a subset of these to the client, ensuring encapsulation and strategic functionality exposure.
  5. Delegated Implementation: One of the pivotal merits of aggregation is the ability to delegate the implementation of specific functionalities to the inner object. The outer object essentially becomes a façade that can harness the capabilities of one or more inner objects.

IV. Implications and Relevance

Aggregation within COM has profound implications for software design and integration:
  1. Component Reusability: Developers can seamlessly integrate and extend existing components, fostering an environment of reusability and modular design.
  2. Reduced Redundancy: By leveraging existing functionalities through aggregation, there is a marked reduction in code duplication and associated maintenance overhead.
  3. Flexibility: Aggregation allows developers to combine functionalities of different objects, leading to versatile and dynamically adaptable software components.

In synthesizing the characteristics of COM aggregation, it becomes evident that this mechanism is a cornerstone for modular and extensible software design within Microsoft's Component Object Model. It encapsulates the principles of reusability, flexibility, and encapsulation, underpinning many of the robust software solutions developed on the COM platform. As the field of software engineering continually evolves, understanding such foundational concepts remains paramount for both researchers and practitioners.
Before jumping into the technical details of aggregation, let us step back and summarize aggregation:
  1. Aggregation supports a composition of objects where the outer object appears to implement the inner object's interfaces. The collection of aggregated objects and the outer object act as one COM object.
  2. Aggregated objects (inner objects) directly expose their interfaces. Unlike containment/delegation, there is no intermediate interface in the outer object that stands between the client and the inner object's interface.
  3. Even though an aggregated/inner object's interfaces are directly exposed to the client, the client is not aware of the aggregated (inner) objects.
  4. Aggregation scenarios can be multilevel. For example, in the example presented in the previous module, the client uses FileManager. FileManager aggregates the FindFile, ReadWriteFile, and ArchiveFile components. The FindFile component aggregates LocalFindFile and RemoteFindFile.

Multilevel aggregation
Multilevel aggregation consisting of IUnknown and InnerCOMObj, IF2

Object's Implementor

There are times when an object's implementor would like to take advantage of the services offered by another, prebuilt object. In addition, it would like this second object to appear as a natural part of the first. COM achieves both of these goals through containment and aggregation. Aggregation means that the containing (outer) object creates the contained (inner) object as part of its creation process and the interfaces of the inner object are exposed by the outer. An object allows itself to be aggregatable or not. If it is, then it must follow certain rules for aggregation to work properly. Namely, all IUnknown method calls on the contained object must delegate to the containing object.

Single Programming Model

A problem related to implementation inheritance is the issue of a single programming model for
  1. in-process objects and
  2. out-of-process/cross-network objects.
In the former case, class library technology (or application frameworks) permits only the use of features or objects that are in a single address. Such technology is far from permitting use of code outside the process space let alone code running on another machine altogether. In other words, a programmer cannot subclass a remote object to reuse its implementation. Similarly, features like public data items in classes that can be freely manipulated by other objects within a single address space do not work across process or network boundaries. In contrast, COM has a single interface-based binding model and has been carefully designed to minimize differences between the in-process and out-of-process programming model. Any client can work with any object anywhere else on the machine or network, and because the object reusability mechanisms of containment and aggregation maintain a client/server relationship between objects, reusability is also possible across process and network boundaries.