Component Object Model
|
|
In programming, the Component Object Model (COM), also known as ActiveX, is a Microsoft technology for software componentry. It is used to enable cross-software communication. Although it has been implemented on several platforms, it is primarily used with Microsoft Windows. Its precursor was object linking and embedding (OLE), and it is to be replaced with the Microsoft .NET framework.
One of the notable thinkers involved in creating the COM architecture was Anthony Williams, who embraced the concept of software components in his papers Object Architecture: Dealing With the Unknown - or - Type Safety in a Dynamically Extensible Class, 1988 and On Inheritance: What It Means and How To Use It, 1990.
Microsoft's earliest object-based technology was Object Linking and Embedding (OLE) 1.0, which was built on top of dynamic data exchange (DDE) and designed specifically for compound documents. (An example of a compound document is a spreadsheet embedded in a Word for Windows document. Make changes to the spreadsheet with Excel and they appear, as if by magic, inside the Word document.) It was introduced with Word for Windows and Excel in 1991, and was later included with Windows, starting with version 3.1 in 1992. Also in 1991, Microsoft introduced Visual Basic controls, or VBX, with Visual Basic 1.0.
In 1993, Microsoft released OLE 2, and created COM as the underlying object model for OLE 2. While OLE 1 was focused on compound documents, COM and OLE 2 were designed to address software components in general. In 1994 OLE controls (OCX) were introduced as the successor to VBX controls. At the same time, Microsoft stated that OLE 2 would just be known as "OLE", and that OLE was no longer an acronym, but a name for all of the company's component technologies.
In early 1996 Microsoft renamed some parts of OLE relating to the Internet ActiveX, and then gradually renamed all OLE technologies as ActiveX, except compound document technology as used in Microsoft Office. Later that year, DCOM was introduced as an answer to CORBA.
While COM had been around since 1993, Microsoft started emphasizing the name COM more around 1997.
| Contents |
COM+
With Windows 2000, a significant extension to COM named COM+ was introduced. At the same time, Microsoft de-emphasized DCOM as a separate entity.
Advantage of COM+ was that it could be run in "component farms", managed with the built-in Microsoft Transaction Server. A component, if coded properly, could be reused by new calls to its initializing routine without unloading it from memory. Components could also be distributed (called from another machine) as was previously only possible with DCOM.
DCOM
Main article: Distributed component object model
Migration from COM to .NET
The COM platform has largely been superseded by the Microsoft .NET initiative. Although COM remains a viable technology (and Microsoft has no plans of discontinuing it), the company is now focusing its marketing efforts on .NET.
There exists a limited backward compatibility in that a COM object may be used in .NET by implementing a runtime callable wrapper (RCW), and .NET objects may be used in COM objects by calling a COM callable wrapper. Additionally, several of the services that COM+ provides, such as transactions and queued components, are still important for enterprise .NET applications.
ActiveX and Internet Security
The embedding of ActiveX into the Internet Explorer web browser created a combination of functions that has led to an explosion of computer virus, trojan and spyware infections. These malware attacks mostly depend on ActiveX for their activation and propagation to other computers. Microsoft has recognized the problem with ActiveX since 1996 when Charles Fitzgerald, program manager of Microsoft's Java team said "If you want security on the 'Net', unplug your computer. ... We never made the claim up front that ActiveX is intrinsically secure." [1] (http://www.javaworld.com/javaworld/jw-03-1997/jw-03-component.web97.html)
Technical details
COM programmers build their software using COM-aware components. Different component types are identified by class IDs (CLSIDs), which are Globally Unique Identifiers, or GUIDs. Each COM component exposes its functionality through one or more interfaces. The different interfaces supported by a component are distinguished from each other using interface IDs (IIDs), which are also GUIDs.
COM interfaces have bindings in several languages, such as C, C++, D, Visual Basic, and several of the scripting languages implemented on the Windows platform. All access to components is done through the methods of the interfaces. This allows techniques such as inter-process, or even inter-computer programming (the latter using the support of DCOM).
All COM components must (at the very least) implement the standard IUnknown interface. Indeed, all COM interfaces are derived from the IUnknown interface. The IUnknown interface consists of three methods: AddRef() and Release(), which implement reference counting and control the lifetime of interfaces; and QueryInterface, which by specifying an IID allows a caller to retrieve references to the different interfaces the component implements. The effect of QueryInterface() is similar to dynamic_cast<> in C++ or casts in D, Java and C#.
COM specifies many other standard interfaces used to allowed inter-component communication. For example, one such interface is IStream, which is exposed by components that have data stream semantics (e.g. a FileStream component used to read or write files). It has the expected Read and Write methods to perform stream reads and writes. Another standard interface is IOleObject, which is exposed by components that expect to be linked or embedded into a container. IOleObject contains methods that allow callers to determine the size of the component's bounding rectangle, whether the component supports operations like 'Open', 'Save' and so on.
A running instance of a component can be obtained by asking the COM runtime library for a class factory and specifying the CLSID of the required component. The returned class factory is then asked to create an instance of the desired component, specifying an IID to obtain a particular interface that the component implements. A client then calls interface methods, and finally releases the interface by calling the Release() method.
Components can describe themselves using COM Type Libraries. A type library contains information such as the CLSID of a component, the IIDs of the interfaces the component implements, and descriptions of each of the methods of those interfaces. Type libraries are typically used by RAD environments such as Visual Basic or Visual Studio to assist in the programming of COM components.
COM programmers are responsible for entering and leaving the COM environment, instantiating and reference counting COM objects, querying objects for version information, coding to take advantage of advanced object versions, and coding graceful degradation of function when newer versions aren't available. COM classes are identified by a Globally Unique Identifier or GUID -- a 128-bit number -- guaranteed unique worldwide. COM classes must be listed by number in The Registry. COM objects may be referenced from within a process, across process boundaries within a computer, and across a network. A COM object watches its reference count and causes itself to disappear once the reference count goes to zero. Vast amounts of software have been written using COM. There is much visible plumbing involved with COM, especially for C++ programmers. The Microsoft .NET framework puts the plumbing in the walls.
See also
External links
- Microsoft COM Technologies (http://www.microsoft.com/com/)
- What OLE is Really About (http://msdn.microsoft.com/library/en-us/dnolegen/html/msdn_aboutole.asp) by Kraig Brockschmidt. An Overview of COM and OLE.
- Component Application Group at Microsoft Research (http://www.research.microsoft.com/comapps/)
de:Component Object Model pl:COM ja:Component Object Model pt:ActiveX sv:COM zh:元件物件模型