AAF and its use of COM
​
The Component Object Model (COM) is currently used at the top level API for AAF SDK. it does not imply that the AAF toolkit is particularly tied to Windows or the Microsoft Development Tools, COM in this instance is simply a discipline for writing and maintaining re-usable code libraries.
​
The use of COM shows that the AAF Code and it's libraries and DLL's or shared objects adhere to the principles of Interface Invariance and provided the mechanisms for supporting a robust third party shared code library.
​
On non-Windows platforms COM support is provided by our own portable library - (on Windows the AAF DLL isn't registered with the Registry and you don't use CoCreateInstance to create Objects).
​
Refer to the routines in the ref-impl/src/com-api/com-dll for the specifics of the underlying ImplAAFRoot and AAFUnknown interfaces.
It might be interesting to note that the Architecture of the SDK is such that a top level API based on COM is not the only alternative, there is an extra layer of abstraction below the COM API where the meat of the methods is implemented. This implementation layer could equally well act as the foundation for a Java API.
The main characteristics of COM-style interfaces are:
-
Invariance of Interface
-
Encapsulation - hiding the implementation
-
Support for QueryInterface dynamic casting (Unique Interface Identifiers)
-
Built-in reference Counting for pointers to Objects
The first thing most people have done when building on top of the AAF COM API is to add some kind of Reference counting and smart pointers. See the new AxExamples or the EDL2AAF project.
​
Further reading
Essential COM, Don Box, Addison Wesley 1998
Inside COM, Dale Rogerson, Microsoft Press 1997
​
Helper Functions
​
The example program InfoDumper probably shows the best structure for using the COM API, Generally it helps to have extra Template Classes to simplify the reference counting, where InfoDumper makes use of IAAFSmartPointer James Cain's EDL2AAF introduces his own glue class cUnknownPtr to achieve the same goal.
Issues of navigation around interfaces...
One school of thought (currently implemented in AAF) is to use QueryInterface exclusively to discover the inheritance hierarchy of a Class. Whilst following the spirit of COM this can lead to a large number of QueryInterface calls while you 'probe in the dark' trying to find what interfaces a particular interface supports.
There is a suggestion that for a later version of the SDK that a new interface be introduced that uses public Interface Inheritance as an alternative to the current system where there is no predictable relation between the different interfaces a particular object can have. In the current scheme the only way to find if an object supports an interface to call QueryInterface on it, even if you know from the implementation that an IAAFSourceClip is also an IAAFComponent.
See [Rogerson] Chapter 8
​
​