Teknik Telekomunikasi    
   
Daftar Isi ☛
(Sebelumnya) Component diagramComponent Pascal (Berikutnya)

Component Object Model

Component Object Model (COM) is a binary-interface standard for software componentry introduced by Microsoft in 1993. It is used to enable interprocess communication and dynamic object creation in a large range of programming languages. COM is the basis for several other Microsoft technologies and frameworks, including OLE, OLE Automation, ActiveX, COM+, DCOM, the Windows shell, DirectX, and Windows Runtime.

Contents

Overview

The essence of COM is a language-neutral way of implementing objects that can be used in environments different from the one in which they were created, even across machine boundaries. For well-authored components, COM allows reuse of objects with no knowledge of their internal implementation, as it forces component implementers to provide well-defined interfaces that are separated from the implementation. The different allocation semantics of languages are accommodated by making objects responsible for their own creation and destruction through reference-counting. Casting between different interfaces of an object is achieved through the QueryInterface() function. The preferred method of inheritance within COM is the creation of sub-objects to which method calls are delegated.

COM is an interface technology defined and implemented as standard only on Microsoft Windows and Apple's Core Foundation 1.3 and later plug-in API,[1] the Windows Communication Foundation (WCF). However, COM objects can be used with all .NET languages through .NET COM Interop. Networked DCOM uses binary proprietary formats, while WCF encourages the use of XML-based SOAP messaging. COM is very similar to other component software interface technologies, such as CORBA and Java Beans, although each has its own strengths and weaknesses.

Unlike C++, COM provides a stable ABI that does not change between compiler releases.[2] This makes COM interfaces attractive for object-oriented C++ libraries that are to be used by clients compiled using different compiler versions.

History

One of the first methods of interprocess communication in Windows was Dynamic Data Exchange (DDE), first introduced in 1987, that allowed sending and receiving messages in so-called "conversations" between applications.

Antony Williams, one of the most notable thinkers involved in the creation of the COM architecture, later distributed two 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 Library in 1988 and On Inheritance: What It Means and How To Use It in 1990. These provided the foundation of many of the ideas behind COM.

Object Linking and Embedding (OLE), Microsoft's first object-based framework, was built on top of 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 Extensions (VBX) with Visual Basic 1.0. A VBX is a packaged extension in the form of a dynamic-link library (DLL) that allows objects to be graphically placed in a form and manipulated by properties and methods. These were later adapted for use by other languages such as Visual C++.

In 1992, when version 3.1 of Windows was released, Microsoft released OLE 2 with its underlying object model. The COM Application binary interface (ABI) was the same as the MAPI ABI, which was released in 1992. While OLE 1 was focused on compound documents, COM and OLE 2 were designed to address software components in general. Text conversations and Windows messages had proved not to be flexible enough to allow sharing application features in a robust and extensible way, so COM was created as a new foundation, and OLE changed to OLE2.

In 1994 OLE custom controls (OCXs) 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 found a new use for OLE Custom Controls, expanding their Web browser's capability to present content, 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+

In order for Microsoft to provide developers with support for distributed transactions, resource pooling, disconnected applications, event publication and subscription, better memory and processor (thread) management, as well as to position Windows as an alternative to other enterprise-level operating systems, Microsoft introduced a technology called Microsoft Transaction Server (MTS) on Windows NT 4.

With Windows 2000, that significant extension to COM was incorporated into the operating system (as opposed to the series of external tools provided by MTS) and renamed COM+. At the same time, Microsoft de-emphasized DCOM as a separate entity. Components that made use of COM+ services were handled more directly by the added layer of COM+, in particular by operating system support for interception. In the first release of MTS, interception was tacked on - installing an MTS component would modify the Windows Registry to call the MTS software, and not the component directly.

Windows 2000 also revised the Component Services control panel application used to configure COM+ components.

An advantage of COM+ was that it could be run in "component farms". Instances of a component, if coded properly, could be pooled and reused by new calls to its initializing routine without unloading it from memory. Components could also be distributed (called from another machine). COM+ and Microsoft Visual Studio provided tools to make it easy to generate client-side proxies, so although DCOM was used to make the remote call, it was easy to do for developers.

COM+ also introduced a subscriber/publisher event mechanism called COM+ Events, and provided a new way of leveraging MSMQ (inter-application asynchronous messaging) with components called Queued Components. COM+ events extend the COM+ programming model to support late-bound events or method calls between the publisher or subscriber and the event system.

.NET

Main article: .NET Framework

Microsoft .NET provides means both to interact with COM+ (via COM-interop-assemblies), and to provide component technology. Microsoft now focuses much of its marketing efforts on .NET, with .NET providing wrappers to the most commonly used COM controls. COM is still often used to hook up complex, high performance code to front end code implemented in Visual Basic or ASP. The .NET framework provides rapid development tools similar to Visual Basic for both Windows Forms and Web Forms with just-in-time compilation, back-end code can be implemented in any .NET Language including C#, Visual Basic and C++/CLI.

Despite this, COM remains the viable technology, providing high performance, powerful and low-bandwidth-consumption remoting and unparallelled stability due to its nearly two decades of existence and improvement. Therefore, Microsoft itself uses COM for modern operating system components like the ribbon control provided in Windows 7 and Windows 8, besides hundreds of other COM components in their standard installation. It is also ideal for script control of applications such as Office or Internet Explorer since it provides an interface for calling COM object methods from a script rather than requiring knowing the API at compile time. The GUID system used by COM has wide uses any time a unique ID is needed.

In addition to being able to leverage COM+ in .NET via the System.EnterpriseServices namespace several of the services that COM+ provides have been duplicated in recent releases of .NET. For example, the System.Transactions namespace in .NET provides the TransactionScope class, which provides transaction management without resorting to COM+. Similarly, queued components can be replaced by Windows Communication Foundation with an MSMQ transport (MSMQ being a native COM component, however).

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

WCF (Windows Communication Foundation) eases a number of COM's remote execution challenges, e.g. allowing objects to be transparently marshalled by value across process or machine boundaries more easily.

Microsoft .NET hides most detail from component creation and therefore eases development. However, any lean, high performance components continue to use the language-independent – while being especially C++-friendly – COM paradigm.

Windows Runtime

Main article: Windows Runtime

Microsoft's new Windows Runtime (or WinRT, not to be confused with Windows RT) programming and application model is essentially a COM-based API, although relying on an enhanced COM. Because of its COM-like basis, Windows Runtime allows relatively easy interfacing from multiple languages, just as COM does, but it's essentially an unmanaged, native API. The API definitions are, however, stored in ".winmd" files, which are encoded in ECMA 335 metadata format, the same format that .NET uses with a few modifications. This common metadata format allows for significantly less overhead when invoking WinRT from .NET applications compared to a P/Invoke, and much simpler syntax.

Security

COM and ActiveX components are run as native code on the user's machine, with no sandboxing. There are therefore few restrictions on what the code can do. The prior practice of embedding ActiveX components on web pages with Internet Explorer did therefore lead to problems with computer virus, trojan and spyware infections. Microsoft recognized the problem with ActiveX as far back as 1996 when Charles Fitzgerald (program manager, Microsoft) said: "We never made the claim up front that ActiveX is intrinsically secure."[5]

Recent versions of Internet Explorer prompts the user before installing ActiveX controls, enabling the user to disallow installation of controls from sites that the user does not trust. The ActiveX controls are signed with digital signatures to guarantee their authenticity. It is also possible to disable ActiveX controls altogether, or to allow only a selected few.

The transparent support for out-of-process COM servers still open up for improved software safety in terms of process isolation. This can be useful for decoupling subsystems of large application into separate processes. Process isolation limits the concequense of state corruption in one process from negatively affecting the integrity of the other processes, since they only communicate through strictly defined interfaces. That way, only the affected subsystem needs to be restarted in order to regain valid state. This is not the case for subsystems within the same process, where a rogue pointer in one subsystem can randomly corrupt other subsystems.

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 (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 GUIDs too.

COM interfaces have bindings in several languages, such as C, C++, Visual Basic, Delphi, 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 implement the IUnknown interface, which consists of three methods: AddRef and Release for reference counting and QueryInterface, which allows the caller to retrieve references to different interfaces the component implements. The effect of QueryInterface is similar to dynamic_cast<> in C++ or casts in Java and C#.

A COM component's 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 interface. 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 requires that if interface B is obtainable from interface A and interface C is obtainable from interface B, then interface C should be retrievable from interface A.

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.

COM specifies many 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.

Classes

A COM class (coclass) is a concrete implementation of one or more interfaces, and closely resembles classes in other object-oriented programming languages. Classes are created based on their class ID (CLSID) or based on their programmatic identifier string (progid).

Like for many other object-oriented languages, COM provides a clear separation of interface from implementation. This distinction is especially strong in COM, where objects cannot be accessed directly, but only through its interfaces. COM also has strong support for multiple implementations of the same interface, so that clients at runtime can choose which implementation of an interface to instantiate.

Interface Definition Language and type libraries

Type libraries contain metadata that represent COM types. However, these types must first be described using Microsoft Interface Definition Language.

This is the common practice in the development of a COM component, i.e. to start with the definition of types using IDL. An IDL file is what COM provides that allows developers to define object-oriented classes, interfaces, structures, enumerations and other user-defined types in a language independent manner. COM IDL is similar in appearance to C/C++ declarations with the addition of keywords such as "interface" and "library" for defining interfaces and collections of classes, respectively. IDL also requires the use of bracketed attributes before declarations to provide additional information, such as the GUIDs of interfaces and the relationships between pointer parameters and length fields.

The IDL file is compiled by the MIDL compiler into a pair of forms for consumption from various languages. For C/C++, the MIDL compiler generates a compiler-independent header file containing struct definitions to match the vtbls of the declared interfaces and a C file containing declarations of the interface GUIDs. C++ source code for a proxy module can also be generated by the MIDL compiler. This proxy contains method stubs for converting COM calls into Remote Procedure Calls, thus enabling DCOM.

An IDL file may also be compiled by the MIDL compiler into a type library (.TLB file). The binary metadata contained within the type library is meant to be processed by language compilers and runtime environments (e.g. VB, Delphi, the .NET CLR etc.). The end result of such TLB processing is that language-specific constructs are produced that represent the COM class defined in the .TLB (and ultimately that which was defined in the originating IDL file).

COM as an object framework

Because COM is a runtime framework, types have to be individually identifiable and specifiable at runtime. To achieve this, globally unique identifiers (GUIDs) are used. Each COM type is designated its own GUID for identification at runtime.

In order for information on COM types to be accessible at both compile time and runtime, COM uses type libraries. It is through the effective use of type libraries that COM achieves its capabilities as a dynamic framework for the interaction of objects.

Consider the following example coclass definition in an IDL :

coclass SomeClass {  [default] interface ISomeInterface;};

The above code fragment declares a COM class named SomeClass which implement an interface named ISomeInterface.

This is conceptually equivalent to defining the following C++ class:

class SomeClass : public ISomeInterface {  ...  ...};

where ISomeInterface is a C++ pure virtual class.

The IDL files containing COM interfaces and classes are compiled into type libraries (TLB) filles, which can later be parsed by clients at runtime to determine which interfaces an object supports, and invoke an object's interface methods.

In C++, COM objects are instantiated with the CoCreateInstance function that takes the class ID (CLSID) and interface ID (IID) as arguments. Instantiation of SomeClass can be implemented as follows:

ISomeInterface* interface_ptr = NULLHRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL,  IID_ISomeInterface, (void**)&interface_ptr);

In this example, the COM sub-system is used to obtain a pointer to an object that implements ISomeInterface interface and coclass CLSID_SomeClass's particular implementation of this interface is required.

Registry usage

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

Registration-free COM

Registration-Free COM (RegFree COM) is a technology introduced with Windows XP that allows Component Object Model (COM) components to store activation metadata and CLSID (Class ID) for the component without using the registry. Instead, the metadata and CLSIDs of the classes implemented in the component are declared in an assembly manifest (described using XML), stored either as a resource in the executable or as a separate file installed with the component.[6] This allows multiple versions of the same component to be installed in different directories, described by their own manifests, as well as XCOPY deployment.[7] This technique has limited support for EXE COM servers[8] and cannot be used for system-wide components such as MDAC, MSXML, DirectX or Internet Explorer.

During application loading, the Windows loader searches for the manifest.[9] If it is present, the loader adds information from it to the activation context [7] When the COM class factory tries to instantiate a class, the activation context is first checked to see if an implementation for the CLSID can be found. Only if the lookup fails is the registry scanned.[7]

Reference counting

All COM objects utilize reference counting to manage object lifetimes. The reference counts are controlled by the clients through the AddRef and Release methods in the mandatory IUnknown interface that all COM objects implement. COM objects are then responsible for freeing their own memory when the reference count drops to zero.

Certain languages (e.g. Visual Basic) provide automatic reference counting so that COM object developers need not explicitly maintain any internal reference counter in their source codes. In C++, a coder may either perform explicit reference counting or use smart pointers to automatically manage the reference counts.

The following are a guidelines for when to call AddRef and Release on COM objects:

  • Functions and methods that return interface references (via return value or via "out" parameter) shall increment the reference count of the returned object before returning.
  • Release must be called on an interface pointer before the pointer is overwritten or goes out of scope.
  • If a copy is made on an interface reference pointer, AddRef should be called on that pointer.
  • AddRef and Release must be called on the specific interface which is being referenced since an object may implement per-interface reference counts in order to allocate internal resources only for the interfaces which are being referenced.

All reference count calls are not sent out to remote objects over the wire; a proxy keeps only one reference on the remote object and maintains its own local reference count.

To simplify COM development, Microsoft introduced ATL (Active Template Library) for C++ developers. ATL provides for a higher-level COM development paradigm. It also shields COM client application developers from the need to directly maintain reference counting, by providing smart pointer objects.

Other libraries and languages that are COM-aware include the Microsoft Foundation Classes, the VC Compiler COM Support,[10] VBScript, Visual Basic, ECMAScript (JavaScript) and Borland Delphi.

Reflection

See also: reflection (computer science)

At the time of the inception of COM technologies, the only way for a client to find out what features an object would offer was to actually create one instance and call into its QueryInterface method (part of the required IUnknown interface). This way of exploration became awkward for many applications, including the selection of appropriate components for a certain task, and tools to help a developer understand how to use methods provided by an object.

As a result, COM Type Libraries were introduced, through which components can describe themselves. 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 Rapid Application Development (RAD) environments such as Delphi, Visual Basic or Visual Studio to assist developers of client applications.

Programming

COM is a language agnostic binary standard that can be developed in any programming language capable of understanding and implementing its binary defined data types and interfaces.

COM implementations are responsible for entering and leaving the COM environment, instantiating and reference-counting COM objects, querying objects for supported interfaces, as well as handling errors.

The Microsoft Visual C++ compiler supports extensions to the C++ language referred to as C++ Attributes.[11] These extensions are designed to simplify COM development, and takes away a lot of the plumbing code required to implement COM servers in C++.[12]

Process and network transparency

COM objects can be transparently instantiated and referenced from within the same process (in-process), across process boundaries (out-of-process), or remotely over the network (DCOM). Out-of-process and remote objects use marshalling to serialize method calls and return values over process or network boundaries. This marshalling is invisible for the client, who accesses the object as if it were a local in-process object.

Threading in COM

In COM, threading issues are addressed by a concept known as "apartment models". Here the term "apartment" refers to an execution context wherein a single thread or a group of threads is associated with one or more COM objects.

Apartments stipulate the following general guidelines for participating threads and objects:

  • Each COM object is associated with one and only one apartment. This is decided at the time the object is created at runtime. After this initial setup, the object remains in that apartment throughout its lifetime.
  • A COM thread (i.e., a thread in which COM objects are created or COM method calls are made) is also associated with an apartment. Like COM objects, the apartment with which a thread is associated is also decided at initialization time. Each COM thread also remains in its designated apartment until it terminates.
  • Threads and objects which belong to the same apartment are said to follow the same thread access rules. Method calls which are made inside the same apartment are performed directly without any assistance from COM.
  • Threads and objects from different apartments are said to play by different thread access rules. Method calls made across apartments are achieved via marshalling. This requires the use of proxies and stubs.

There are three types of Apartment Models in the COM world: Single-Threaded Apartment (STA), Multi-Threaded Apartment (MTA), and Neutral Apartment. Each apartment represents one mechanism whereby an object's internal state may be synchronized across multiple threads.

The Single-Threaded Apartment (STA) model is a very commonly used model. Here, a COM object stands in a position similar to a desktop application's user interface. In an STA model, a single thread is dedicated to drive an object's methods, i.e. a single thread is always used to execute the methods of the object. In such an arrangement, method calls from threads outside of the apartment are marshalled and automatically queued by the system (via a standard Windows message queue). Thus, there is no worry about race conditions or lack of synchronicity because each method call of an object is always executed to completion before another is invoked.

If the COM object's methods perform their own synchronization, multiple threads dedicated to calling methods on the COM object are permitted. This is termed the Multiple Threaded Apartment (MTA). Calls to an MTA object from a thread in an STA are also marshaled. A process can consist of multiple COM objects, some of which may use STA and others of which may use MTA. The Thread Neutral Apartment allows different threads, none of which is necessarily dedicated to calling methods on the object, to make such calls. The only provision is that all methods on the object must be serially reentrant.


Criticisms

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

Message pumping

When an STA is initialized it creates a hidden window that is used for inter-apartment and inter-process message routing. This window must have its message queue regularly pumped. This construct is known as a message pump. On earlier versions of Windows, failure to do so could cause system-wide deadlocks. This problem is complicated by some Windows APIs that initialize COM as part of their implementation, which causes a leak of implementation details.

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 reference to the object reacting to the event, the object's reference count will never reach zero.

Reference cycles are typically broken using either out-of-band termination or split identities. In the out of band termination technique, an object exposes a method which, when called, forces it to drop its references to other objects, thereby breaking the cycle. In the split identity technique, a single implementation exposes two separate COM objects (also known as identities). This creates a weak reference between the COM objects, preventing a reference cycle.

DLL Hell

Because in-process COM components are implemented in DLL files and registration only allows for a single version of a DLL per CLSID they might in some situations be subject to the "DLL Hell" effect. Registration-free COM capability eliminates this problem.

See also

References

  1. ^ http://developer.apple.com/library/ma c/#documentation/CoreFoundation/Conce ptual/CFPlugIns/Concepts/conceptual.h tml#//apple_ref/doc/uid/20001160-1029 10-BAJFDFFC
  2. ^ Microsoft forum: Binary compatibility across Visual C++ versions
  3. ^ Runtime Callable Wrapper — MSDN Library
  4. ^ COM callable wrapper — MSDN Library
  5. ^ http://replay.waybackmachine.org/2006 0810235058/http://www.javaworld.com/j avaworld/jw-03-1997/jw-03-component.w eb97.html
  6. ^ "Assembly Manifests". MSDN. http://msdn.microsoft.com/en-us/libra ry/aa374219(VS.85).aspx. Retrieved 2009-11-05.
  7. ^ a b c Dave Templin. "Simplify App Deployment with ClickOnce and Registration-Free COM". MSDN Magazine. http://msdn.microsoft.com/en-us/magaz ine/cc188708.aspx. Retrieved 2008-04-22.
  8. ^ "How to use an out-of-process COM server without its tlb file". http://stackoverflow.com/questions/23 69181/how-to-use-an-out-of-process-co m-server-without-its-tlb-file. Retrieved 2011-04-16.
  9. ^ "Concepts of Isolated Applications and Side-by-side Assemblies". MSDN. http://msdn.microsoft.com/en-us/libra ry/ms235531(VS.80).aspx. Retrieved 2009-11-05.
  10. ^ "Compiler COM Support". MSDN. Microsoft. http://msdn.microsoft.com/en-us/libra ry/h31ekh7e.aspx.
  11. ^ Microsoft MSDN: C++ Attributes Reference
  12. ^ MSDN Magazine: C++ Attributes: Make COM Programming a Breeze with New Feature in Visual Studio .NET

External links

(Sebelumnya) Component diagramComponent Pascal (Berikutnya)