A set of rules governing how certain ComComponent''s'' should behave in order to interact with other ComComponent''s''.

Basically when you support ComAutomation, you follow a few basic guidelines:
*Your component's default interface must derive from IDispatch
*You must use only Automation compatible types (anything that can be stored in a ComVariant)
*ToDo: add more details

To be useful to the clients, you must "make your application's object model available as COM objects (with IDispatch interfaces)."

----
ComAutomation is a VERY heavily argued element of COM. It was created solely to facilitate the VisualBasic language in its early incarnations. 

Some people believe that ComAutomation, the IDispatch interface mostly, should really be done away with because there are plenty of other ways to achieve the same results without requiring the author of such ComComponent''s'' to incorporate functionality into each individual component. Essentially, IDispatch is a step backwards in COM, which is based on InterfaceBasedProgramming principles, because it limits environments that '''depend''' on it's presence to a single interface. There are several hacks around this, but in the end, it ruins the entire concept.

''COM needs a generic run-time data-driven client interface that can call functions on normal (non-IDispatch) COM interfaces.  Like CORBA's DynamicInvocationInterface.''

Exactly... and given the ObjectModel that exists for working with a TypeLibrary, the client, say a ScriptingEngine, could actually perform all the work itself. However, an argument for IDispatch is that the server can control what named elements it supports at run-time and perform it's own, non-standard, mapping of names. Of course today we have IDispatchEx, which is actually better modeled for supporting such functionality... the catch is it extends IDispatch. =(

Legacy... ain't it fun? ;)

----
CategoryComponentObjectModel