The OLE Automation Protocol extends the use of DCOM by providing support for marshaling an additional set of types (known as automation types) and by providing support for exposing COM components to automation clients (such as scripting engines) through a late-bound calling alternative to the traditional COM calls. Additionally, the OLE Automation Protocol specifies how a type browser can discover and interpret type information provided by a type description server.
The automation client and server can be present on the same machine, or on different machines connected by a network. Automation takes advantage of functionality provided by the Microsoft Component Object Model (for more information, see [MSDN-COM]) and the Microsoft Distributed Component Object Model (as specified in [MS-DCOM]) for creating, activating, and managing the lifetime of the objects exposed by an automation server.
To support late-bound calling, the OLE Automation Protocol specifies the following:
How a server defines a set of automation methods that can be dispatched, based on a dispatch ID (DISPID).
How the server provides a way to map a method name to the DISPID.
How the server performs the late-bound call, based on the DISPID.
The automation methods are defined by using extensions to the IDL language specified in [C706] sections 6, 7, 8, 9, 10, 11, 12, 13, and 14. These extensions provide the definition of automation interfaces containing automation methods and properties. Each IDL definition of an automation method and property can have a unique (per interface) integer value associated with it. This value is defined as a DISPID and is statically discoverable (from the IDL specification of the method), and dynamically discoverable (through a call to IDispatch::GetIDsOfNames (section 184.108.40.206)). This value is then used by automation clients to invoke the automation method, or to set or retrieve an automation property (through a call to IDispatch::Invoke).
To support this late-bound calling mechanism, Automation defines a set of types, VARIANT (section 2.2.29) being the most important of them. A VARIANT can be thought of as a discriminated union of all automation-supported types. The OLE Automation Protocol imposes the following restriction on the automation interfaces: All types of method arguments and properties can be stored as VARIANT structures.
The following illustration shows a generic automation call sequence:
Figure 1: Generic Automation call
This automation call response can be optimized if the automation client knows the DISPIDs associated with an automation server's method at compile time, and forgoes the initial call to GetIDsOfNames:
Figure 2: Optimized Automation call
To support type description and discovery, the OLE Automation Protocol specifies:
How the automation server supports queries for type-description support.
How to specify an extended set of capabilities and relationships using automation IDL extensions.
How a server can provide access to the information specified in the IDL.
An automation server specifies that it provides type information by implementing IDispatch::GetTypeInfoCount (section 220.127.116.11), and exposes access to the type description server that describes the server's dispinterface by implementing IDispatch::GetTypeInfo (section 18.104.22.168).
The following diagram illustrates a generic query for type information.
Figure 3: Generic query for type information
To support exposing type information related to COM servers, the OLE Automation Protocol specifies the set of types that are used to encapsulate semantic information associated with a COM server, with the interfaces it implements, and with the methods and properties defined on those interfaces (TYPEATTR (section 2.2.44), FUNCDESC (section 2.2.42), and VARDESC (section 2.2.43) being the most important), in addition to the set of interfaces that a server must implement to provide COM clients with access to the type information (ITypeInfo being the central one).
Figure 4: Generic query for type information related to COM servers