[Previous] [Contents] [Next]

Chapter Five

Automation

Automation, the popular name for the IDispatch interface, was originally designed by the Visual Basic group at Microsoft. The Automation facility allows applications to expose their functionality for use by other programs. For example, full-featured applications such as Microsoft Word can expose a hierarchy of objects through Automation. Each object supports specific properties, methods, and events, enabling client programs to take advantage of the rich features offered in such applications by automating their use. An application that is normally driven by the end-user can thus be controlled by another program without any user involvement.1

Imagine developing a business application that performs standard data entry and reporting. It would be nice if the program could create graphs of the data as well. Rather than writing the code to produce the graphs, you can use the Automation objects exposed by Microsoft Excel to send the data to Excel and then ask Excel to print some fancy-looking graphs; the user never even has to see Excel on the screen. This type of integration is something that programmers only dreamed of a few years ago.

You might wonder why you need a specific facility such as Automation to expose the functionality of an application to other programs. After all, isn't that exactly the type of integration and reuse that was envisioned by the designers of COM+? Certainly an application can expose its capabilities via custom interfaces. But with this approach, each component typically defines its own set of custom interfaces. This is not a real problem for most applications, since each client program is typically designed to work with a certain set of interfaces germane to the data being processed. However, certain generic programs such as Microsoft Visual Basic and the Microsoft Java VM must deal with a wide variety of components, many of which might implement custom interfaces that did not even exist when those programs were written. In such cases, it can be difficult, if not impossible, for a client application to access a custom interface about which it has no prior knowledge.

So in addition to allowing applications to expose their functionality in a standard way, Automation was also developed to enable high-level languages such as Visual Basic to access components. Before the advent of type libraries, it was difficult for high-level environments to gain access to custom interfaces about which they had no information, whereas support for the standard IDispatch interface could be programmed into an environment by its developers. The environment could then work with any component that supported IDispatch, regardless of what services the component provided.

Over time, however, it became apparent that languages like Visual Basic could access components directly via custom interfaces as long as some information about the interfaces implemented by the component was available. This requirement was satisfied with the development of type libraries; type libraries have in turn diminished the importance of the IDispatch interface. It might seem obvious that a generic development environment such as Visual Basic can learn about an unknown custom interface by reading the component's type library. Visual Basic assumes that type information describing the custom interface is available, but this might not always be the case. Besides, the Automation facility was designed before type information was prevalent.

Automation has since been refashioned for use by interpreted scripting languages such as Visual Basic Scripting Edition (VBScript) and JScript that run in environments such as Microsoft Internet Explorer, Microsoft Internet Information Server (IIS), and the Microsoft Windows Scripting Host. These environments continue to rely only on Automation and have only limited support for type information. (Scripting languages can reference only the constants defined in a component's type library.) So implementing IDispatch remains a requirement for components to be accessed from these languages. Recently, the Automation facility was extended with the definition of the IDispatchEx interface, which supports more dynamic objects, whose properties and methods can change at run time. Thus Automation remains an important facility of COM+ that brings an extra level of interoperability to the system.