| Previous | Table of Contents | Next |
In OLE, the Interworking Object Model is principally mapped to the architectural abstraction known as the Component Object
Model (COM). Functionally, COM allows an object to expose its interfaces in a well-defined binary form (that is, a virtual
function table) so that clients with static compile-time knowledge of the interface’s structure, and with a reference to an
instance offering that interface, can send it appropriate requests. Most COM interfaces are described in Microsoft Interface
Definition Language (MIDL).
COM supports an implementation typing mechanism centered around the concept of a COM class. A COM class has a well-defined
identity and there is a repository (known as the system registry) that maps implementations (identified by class IDs) to specific
executable code units that embody the corresponding implementation realizations.
COM also provides an extension called Automation. Interfaces that are Automation-compatible can be described in Object Definition
Language (ODL) and can optionally be registered in a binary Type Library. Automation interfaces can be invoked dynamically
by a client having no compile-time interface knowledge through a special COM interface (IDispatch). Run-time type checking
on invocations can be implemented when a Type Library is supplied. Automation interfaces have properties and methods, whereas
COM interfaces have only methods. The data types that may be used for properties and as method parameters comprise a subset
of the types supported in COM. Automation, for example, does not support user-defined constructed types such as structs or
unions.
Thus, use of and interoperating with objects exposing Automation interfaces is considerably different from other COM objects.
Although Automation is implemented through COM, for the purposes of this document, Automation and COM are considered to be
distinct object models. Interworking between CORBA and Automation will be described separately from interworking with the
basic COM model.