COM was originally designed to provide core communication functionality and to enable the broadening of this functionality through extensions. COM itself has extended its core functionality by defining specialized sets of interfaces for specific purposes.
The following lists some of the services COM extensions currently provide.
Automation refers to the ability of an application to control the objects in another application programmatically. Automation servers are the objects that can be controlled by other executables at runtime. | |
ActiveX controls are specialized in-process servers, typically intended for embedding in a client application. The controls offer both design and runtime behaviors as well as events. | |
Active Server Pages are scripts that generate HTML pages. The scripting language includes constructs for creating and running Automation objects. That is, the Active Server Page acts as an Automation controller. | |
Objects that support linking and embedding, drag-and-drop, visual editing, and in-place activation. Word documents and Excel spreadsheets are examples of Active Documents. | |
COM+ Event and event subscription objects |
Objects that support the loosely coupled COM+ Events model. Unlike the tightly coupled model used by ActiveX controls, the COM+ Events model allows you to develop event publishers independently of event subscribers. |
A collection of static data structures, often saved as a resource, that provides detailed type information about an object and its interfaces. Clients of Automation servers, ActiveX controls, and transactional objects expect type information to be available. |
The following diagram illustrates the relationship of the COM extensions and how they are built upon COM:
COM objects can be visual or non-visual. Some must run in the same process space as their clients; others can run in different processes or remote machines, as long as the objects provide marshaling support. The following table summarizes the types of COM objects that you can create, whether they are visual, process spaces they can run in, how they provide marshaling, and whether they require a type library.
COM object requirements
Object |
Visual Object? |
Process space |
Communication |
Type library |
Active Document |
Usually |
In-process, or out-of-process |
OLE Verbs |
No |
Automation Server |
Occasionally |
In-process, out-of-process, or remote |
Automatically marshaled using the IDispatch interface (for out-of process and remote servers) |
Required for automatic marshaling |
ActiveX Control |
Usually |
In-process |
Automatically marshaled using the IDispatch interface |
Required |
COM+ |
Occasionally |
In-process for MTS,any for COM+ |
Automatically marshaled via a type library |
Required |
In-process custom interface object |
Optionally |
In-process |
No marshaling required for in-process servers |
Recommended |
Other custom interface object |
Optionally |
In-process,out-of-process, or remote |
Automatically marshaled via a type library; otherwise, manually marshaled using custom interfaces |
Recommended |
Copyright(C) 2008 CodeGear(TM). All Rights Reserved.
|
What do you think about this topic? Send feedback!
|