Component Object Model

(Redirected from ActiveX)

Categories: Object-oriented programming | Programming paradigms | Components

Component Object Model, or COM, is a Microsoft platform for software componentry. It is used to enable cross-application communication and dynamic object creation in any programming language that supports the technology. COM is often used in the software development world as an umbrella term that encompasses the OLE, ActiveX, COM+ and DCOM technologies. COM has been around since 1993, however Microsoft only really started emphasizing the name around 1997.

Although it has been implemented on several platforms, it is primarily used with Microsoft Windows. COM is expected to be replaced to at least some extent by the Microsoft .NET framework.

Contents 1 History 2 Related technologies 2.1 COM+ 2.2 DCOM 2.3 .NET 3 Internet Security 4 Technical details 4.1 Interfaces 4.2 Registry 4.3 Reference Counting 4.4 Instantiation 4.5 Reflection 4.6 Programming 4.7 Application and Network Transparency 5 Criticisms 5.1 Environment Initialization 5.2 Reference Counting 5.3 DLL Hell 6 References 7 See also 8 External links

History

Anthony Williams, one of the more notable thinkers involved in the creation of the COM architecture, distributed a couple of internal papers in Microsoft that embraced the concept of software components; Object Architecture: Dealing With the Unknown - or - Type Safety in a Dynamically Extensible Class in 1988 and On Inheritance: What It Means and How To Use It in 1990. These provided the foundation of many, if not all, of the ideas behind the basics of COM.

From many of these ideas spawned Microsoft's first object-based framework, OLE, which is short for Object Linking and Embedding. OLE was built on top of dynamic data exchange (DDE) and designed specifically for compound documents. It was introduced with Word for Windows and Excel in 1991, and was later included with Windows, starting with version 3.1 in 1992. An example of a compound document is a spreadsheet embedded in a Word for Windows document; as changes are made to the spreadsheet within Excel, they appear automatically inside the Word document.

In 1991, Microsoft introduced Visual Basic controls, or VBX, with Visual Basic 1.0.

In 1993, Microsoft released OLE 2 with COM as the underlying object model. 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.

Later, in early 1996, Microsoft renamed some parts of OLE relating to the Internet ActiveX, and gradually renamed all OLE technologies to ActiveX, except the compound document technology that was used in Microsoft Office. Later that year, DCOM was introduced as an answer to CORBA.

Related technologies

COM was the major software development platform for Windows and, as such, influenced development of a number of supporting technologies.

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

.NET

The COM platform has largely been superseded by the Microsoft .NET initiative and Microsoft now focuses its marketing efforts on .NET. To some extent, COM is now deprecated in favour of .NET. Despite this, COM remains a viable technology with an important software base – for example the popular DirectX 3D rendering SDK is based on COM. Microsoft has no plans for discontinuing COM or support for COM.

Several of the services that COM+ provides, such as transactions and queued components, are still important for enterprise .NET applications.

There is limited support for backward compatibility. A COM object may be used in .NET by implementing a runtime callable wrapper (RCW). .NET objects that conform to certain interface restrictions may be used in COM objects by calling a COM callable wrapper. From both the COM and .NET sides, objects using the other technology appear as native objects.

.NET's remoting model solves a number of COM's remote execution shortcomings, allowing objects to be transparently marshalled by reference or value across process or machine boundaries.

Internet Security

The embedding of COM into the Internet Explorer web browser (under the name of ActiveX) created a combination of problems 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 recognized the problem with ActiveX as far back as 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] ActiveX as it is currently implemented is intrinsically insecure and is the biggest weakness of Internet Explorer not addressed by Windows XP Service Pack 2.

As COM and ActiveX components are run as native code on the user's machine, there are no restrictions on what the code can and cannot do. Many of these problems have been addressed with the creation of the .NET platform, however.

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).

Interfaces

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#.

A COM components interfaces are required to exhibit the reflexive, symmetric, and transitive properties. The reflexive property refers to the ability for the QueryInterface() call on a given interface with the interface's ID to return the same instance of the object. The symmetric property requires that when interface B is retrieved from interface A via QueryInterface(), interface A is retrievable from interface B as well. The transitive property is similar to the symmetric property, but requires that if interface B is obtainable from interface A and interface C is obtainable from interface B, then interface A should be retrievable from interface C.

An interface consists of a pointer to a virtual function table that contains a list of pointers to the functions that implement the functions declared in the interface, in the same order that they are declared in the interface. This technique of passing structures of function pointers is very similar to the one used by OLE 1.0 to communicate with its system libraries.

COM specifies many other standard interfaces used to allow 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.

Registry

In Windows, COM classes, interfaces and type libaries are listed by GUIDs in the registry. The COM libaries use the registry to locate either the correct local libraries for each COM object or the network location for a remote service.

Reference Counting

COM objects use a technique called reference counting to ensure that object is properly disposed of when all code that uses the object has finished. A COM object is responsible for freeing its own memory once the reference count goes to zero.

Instantiation

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.

Reflection

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.

Programming

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.

Application and Network Transparency

COM objects may be instantiated and referenced from within a process, across process boundaries within a computer, and across a network, using the DCOM technology. Out-of-process and remote objects may use marshalling to send method calls and return values back and forth. The marshalling is invisible to the object and the code using the object.

Criticisms

Since COM has a fairly complex implementation, programmers can be distracted by some of the "plumbing" issues.

Environment Initialization

COM requires that the programmer call the CoInitialize[Ex] and CoUninitialize methods on each thread in the program that requires COM functionality. In addition, code using the OLE clipboard or drag and drop must call the OleInitialize and OleUninitialize methods. Since some threads in the system may be created by non-COM-aware libraries, the programmer must take care in using any of the COM library methods on a thread that was not created by the program itself.

Reference Counting

Reference counting within COM may cause problems if two or more objects are circularly referenced. The design of an application must take this into account so that objects are not left orphaned.

Objects may also be left with active reference counts if the COM "event sink" model is used. Since the object that fires the event needs a references to the object reacting to the event, the objects reference count will never reach zero.

DLL Hell

Because the location of each component is stored in a system-wide location (the Windows registry), there can be only one version of a certain component installed. Thus, COM seriously suffers from DLL hell, where two or more applications require different versions of the same component.

Additionally, since COM uses the registry intensively, it is sensitive to registry corruption.

References

• "COM: A Brief Introduction." Accessed July 30, 2005.

See also

• component

External links

• Microsoft COM Technologies
• What OLE is Really About by Kraig Brockschmidt. An Overview of COM and OLE.
• Component Application Group at Microsoft Researchde:Component Object Model

es:Component object model fr:Component Object Model hu:Component Object Model ja:Component Object Model pl:COM pt:ActiveX ru:COM sv:COM zh:组件对象模型