OLE Automation

In Microsoft Windows applications programming, OLE Automation (later renamed to simply Automation) is an inter-process communication mechanism created by Microsoft. It is based on Component Object Model (COM) that was intended for use by scripting languages – originally Visual Basic – but now are used by languages run on Windows. It provides an infrastructure whereby applications called automation controllers can access and manipulate (i.e. set properties of or call methods on) shared automation objects that are exported by other applications. It supersedes Dynamic Data Exchange (DDE), an older mechanism for applications to control one another. As with DDE, in OLE Automation the automation controller is the "client" and the application exporting the automation objects is the "server".

Usage

Automation was designed with the ease of scripting in mind, so controllers often provide languages such as Visual Basic for Applications to end users, allowing them to control automation objects via scripts. Automation objects can be written in conventional languages such as C++, but the C++ syntax for COM (and therefore Automation) is complex and not very programmer-friendly. In contrast, languages such as Visual Basic and Borland Delphi provide a convenient syntax for Automation which hides the complexity of the underlying implementation.

Interfaces

An Automation object is a COM object implementing the IDispatch interface (for details on interfaces and calling conventions, see Component Object Model). Automation objects are referred to as ActiveX objects, while an application that manipulates an ActiveX object is referred to as an ActiveX Client. This interface exposes four methods, the most important of which is Invoke. This method allows calling methods of a class by name, with an arbitrary number of parameters. Neither the name of the method nor the number (and exact types) of parameters need to be known at compile time, as it is the case for COM objects not supporting Automation; moreover, in scripting languages there is no "compile time" at all. This technique is called late binding.

Most existing COM components are Automation-compliant and furthermore allow both late binding and traditional, compile-time early binding. This is achieved by implementing so-called dual interfaces, which are interfaces derived from IDispatch. Generally, both late and early binding expose the same functionality for Automation clients; languages such as Visual Basic and Delphi, as well as some C++ libraries, which provide a higher level of abstraction for COM, make sure that all Automation components created in these languages correctly duplicate their interfaces with late and early binding.

Generally, implementing early binding is more troublesome. Late binding is slower, but more reliable, as it does not require binary compatibility between versions of the same component. For late binding, a client only needs to know the name (or CLSID) of the desired object and the names and parameters of methods it actually uses, while for early binding, the client needs to know the complete definition and identifier (IID) for every interface requested, as well as the exact position of each method in the interface vtable. This is, however, more a problem of COM in general rather than Automation, as early binding relies on traditional COM calling conventions.

Automation servers may be implemented as single-use or multi-use. For the former, each client connects to an individual instance of the server, with an individual instance of its class factory. For the latter, many clients connect to a single server, sharing that server's class factory across all clients.

The servers for the automation objects may be either out-of-process executables or in-process DLLs.

Type libraries

In order to automate an application, the developer of an automation controller must know the object model that is employed by the target application exporting activation objects. This requires that the developer of the target application publicly document its object model. Development of automation controllers without knowledge of the target application's object model is "difficult to impossible". Because of these complications, Automation components are usually provided with type libraries, which contain metadata about classes, interfaces and other features exposed by an object library. Interfaces are described in Microsoft Interface Definition Language. Type libraries can be viewed using various tools, such as the Microsoft OLE/COM Object Viewer (oleview.exe, part of the Microsoft Platform SDK) or the Object Browser in Visual Basic (up to version 6) and Visual Studio .NET. Type libraries are used to generate Proxy pattern/stub code for interoperating between COM and other platforms, such as Microsoft .NET and Java. For instance, the .NET Framework SDK includes tools that can generate a proxy .NET DLL to access Automation objects using both early binding (with information about interfaces extracted from a type library) and late binding (via IDispatch, mapped to the .NET Reflection API), with the built-in .NET-to-COM bridge called COM Interop. While Java lacks built-in COM support, toolsets like JACOB and jSegue can generate proxy source code (consisting of two parts, a set of Java classes and a C++ source for a Java Native Interface DLL) from type libraries. These solutions only work on Windows.

Microsoft has publicly documented the object model of all of the applications in Microsoft Office, and some other software developers have also documented the object models of their applications. Object models are presented to automation controllers as type libraries, with their interfaces described in ODL.

Language support

Automation is available for a variety of languages, including, but not limited to:

• ABAP
• C
• C++ (directly or via a library like MFC or ATL)
• Visual Basic and Visual Basic for Applications
• Delphi
• Microsoft .NET languages
• APL (most Windows versions)
• Java (only with third-party tools)
• JScript and VBScript
• Open Object Rexx
• Perl
• PHP
• PowerBuilder
• Python
• Ruby (via the 'win32ole' library included in the standard Ruby 1.8.x or later distribution)
• Tcl
• Visual DataFlex
• WinBatch

Name confusion

Automation objects do not necessarily use Microsoft OLE, which stands for Object Linking and Embedding — currently only a subset of COM — although some of Automation objects (which are a special type of COM objects) can be used in OLE and/or ActiveX environments. The confusion has its roots in Microsoft's earlier (rather vague) definition of OLE, which was previously more or less a synonym of COM — to the point that the acronym "OLE" frequently appears in legacy COM code, like parts of the MFC library.

Notes

OLE Automation in general

• Microsoft Corporation (December 1993). OLE 2 Programmer's Reference: Creating Programmable Applications with OLE Automation v. 2. Programmer's Reference Library. Microsoft Press. ISBN 1-55615-629-4. 
• Kraig Brockschmidt (1995). Inside OLE. Microsoft Press. 
• Microsoft Corporation (1996). OLE Automation Programmer's Reference. Programmer's Reference Library. Microsoft Press. ISBN 1-55615-851-3. 

Object models for specific applications

• Microsoft Corporation (1999). Microsoft Office 2000 Visual Basic for Applications Language Reference. Microsoft Press. ISBN 1-57231-955-0.  — full printed documentation of the object model of Microsoft Office

See also

• Object linking and embedding
• Component Object Model

External links

• OLE Automation General paper on the introduction and problems implementing OLE.
• "VOLE - A Neat C++ COM/Automation Driver" — an open-source, compiler-independent C++ COM Automation driver library, for use when having to drive IDispatch directly. VOLE is highly robust, fully encapsulates all "low-level" aspects of IDispatch, and is very flexible, taking and returning normal C++ types.

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.