Component Object Model

Component Object Model ActiveX and OLE rest on the foundation of COM Understanding COM is a prerequisite to understanding anything else in ActiveX or OLE

Components

Benefits of Components – Flexibility Program for User A Program for User B

Benefits of Components – Component Libraries New Program

Benefits of COM – Distributed Components Network

Component Object Model How should one chunk of software access the services provided by another chunk of software? COM: A standard approach to access all kinds of software services, regardless of how they are provided COM is transforming the way software is constructed

Benefits of COM Offers the benefits of object orientation Provides consistency Is language independent COM defines a binary interface that objects must support Simple and efficient versioning Available on Windows, Windows NT, Macintosh, MVS up to now DCOM allows COM objects on all kinds of systems to interact

Communications between Software OS Application lib

Basic COM Concept COM Binary Code of a Client Class Library Interface Server Class Interface COM Library Binary Code of a Client Class

Basic COM Concept COM object Server Interface

Basic COM Concept COM object Client

Basic COM Concept OS Application lib

RemoveFromDictionary( ) A COM Object COM Object TextTools Client LookUpWord( ) AddToDictionary( ) RemoveFromDictionary( ) ReturnSynonym( )

Identifying an Interface Human-readable name ISpellChecker, IThesaurs Globally Unique Identifier (GUID) Interface Identifier (IID) Each GUID is unique in time and space Timestamp Address on the machine’s network interface card 16 bits

GUID Generator

Interface Definition Language [ object, uuid( E7CD0D00-1827-11CF- 9946444553540000) ] interface ISpellChecker : IUnknown{ import “unknown.idl”; HRESULT LookUpWord( [in] OLECHAR word[31], [out] boolean *found ); HRESULT AddToDictionary( [in] OLECHAR word[31]); HRESULT RemoveFromDictionary( }

Immutability of the Interfaces Once an interface has been implemented in released software, it cannot be changed To add new functionality or to modify existing functionality requires defining an entirely new interface, with a new and different IID The creator of the software is free to stop supporting the original interface but is absolutely prohibited from changing it

New Version Problem A COM object that supports ISpellChecker Add support for a thesaurus function through IThesaurus Effect on the client using the old version with the old or new version installed Effect on the client using the new version with the new version installed Effect on the client using the new version with the old version installed

Changing Features to an Interface The object’s creator must define a new interface, say ISpellChecker2 that includes the new or changed methods and the COM object continues to support ISpellChecker as before, but it now also support ISpellChecker2 Clients that are unaware of the upgrade never ask for a pointer to ISpellChecker2 and so aren’t affected by the changes – they continue to use ISpellChecker as before

IUnknown::QueryInterface 1 A Client COM object 2 B 3

Reference Counting Whenever the object passes out a pointer to one of its interface, it adds 1 to reference count. If one client passes an interface pointer to another client, the client who receives the pointer must invoke the AddRef method using that pointer The client must call Release on the interface pointer to decrement the reference count when it has finished using the interface An object destroys itself when its reference count drops to 0

Binary Format of an Interface Object Client QueryInterface( ) {…} Pointer to Method 1 AddRef( ) {…} Pointer to Method 2 Release( ) {…} Pointer to Method 3 LookUpWord( ) {…} Pointer to Method 4 Pointer to Method 5 AddToDictionary( ) {…} Pointer to Method 6 RemoveFromDictionary( ) {…} vtable

COM Classes Class identifier (CLSID) An object of a specific class supports a certain set of interfaces Adding interfaces to an object without changing its class is not prohibited by COM An object’s class identifies a particular implementation of a group of interfaces It’s possible to have many classes supporting the same set of interfaces

Kinds of COM Servers Machine X Machine Y

COM Library The COM library implements a group of functions that supply basic services to objects and their clients The COM library’s services are accessed through ordinary function calls The names of COM library functions usually begin with the prefix Co- for example, CoCreateInstance

System Registry The classes of all objects that the COM library will be asked to create on this machine must be registered Registry mapping includes CLSID Kinds of servers Pathname for the file containing the server’s DLL or executable, or for where to find remote server’s executable

Creating a Single Object 4 Client Object Server 3 1 2 COM library CLSID_X DLL CLSID_Y EXE ……

Class Factories Class factory is a kind of objects that can create objects of one specific class Class factories are COM objects in their own right – accessed via their interfaces CoCreateInstance uses a class factory that it hides from the client CoCreateInstance uses the methods in the IClassFactory interface

IClassFactory Interface As a class factory, an object must support the IClassFactory interface IClassFactory CreateInstance LockServer IClassFactory2 A client calls CoGetClassObject to get a pointer to a class factory

Using Class Factory Client Class Factory Object 4 3 2 1 Server

Emulation An old class is replaced by a new class with different CLSID A COM library function CoTreatAsClass: when used to create an object using the old CLSID will result in instantiating an object with the new CLSID (setting up an emulation relationship between the two CLSIDs in the system registry)

Initializing COM Objects A client usually asks a newly created objects to initialize itself The object’s data must be stored in a persistent way The first interface pointer a client requests when a new object is created is usually the one for an interface containing the object’s initialization function

Calling Sequence in VC++ (1/2) CLSID clsid; IClassFactory* pClf; IUnknown* pUnk; CoInitialize(NULL); ::CLSIDFromProgID(L“TestTools”, &clsid); ::CoGetClassObject(clsid, IID_IClassFactory, (void**) &pClf);

Calling Sequence in VC++ (2/2) pClf-> CreateInstance(IID_Iunknown, (void**)&pUnk); pUnk-> QueryInterface(IID_ISpellChecker, (void**)&pSpl); pSpl->LookUpWord( “Test”, found ); pClf->Release(); pUnk->Release(); pSpl->Release(); CoFreeUnusedLibraries(); CoUninitialize();

Reusing COM Objects One COM object can’t reuse another’s code through inheritance Containment (delegation) Aggregation

Marshaling and Type Information Marshaling makes that the client can invoke the methods in the same way, regardless of where the object is implemented To acquire the information necessary to perform marshaling, and sometimes for other reasons as well, it can be useful to obtain type information about the project

Accessing a COM Object in an In-Process Server Client Object Client process

Accessing a COM Object in a Local Server Proxy Object Client Stub Client process Server Process Single machine

Accessing a COM object in a Remote Server Proxy Object Stub Client Client process Server Process Machine X Machine Y

Marshaling and Unmarshaling Packaging a call’s parameters into a standard format for transmission Unmarshaling Unpackaging from the standard format into a format appropriate for the receiving process Marshaling Code (Marshaler) MIDL compiler can read the IDL description of an interface and automatically generate the necessary marshalling code for this interface, contained in a proxy and a stub

Type Information Type information includes a description of everything a client needs to know to use an object’s service. For example, the type information of an object includes a list of the interface’s methods and properties, along with a description of the parameters for those methods. All type information today should be defined using IDL

Type Library Interface and Library definitions In IDL MIDL compiler Proxies Stubs Type library Other files

IDL Example [ object,uuid( E7CD0D00-1827-11CF-9946- 444553540000) ] interface ISpellChecker : IUnknown{ import “unknown.idl”; HRESULT LookUpWord( [in] OLECHAR word[31], [out] boolean *found ); HRESULT AddToDictionary( [in] OLECHAR word[31]); HRESULT RemoveFromDictionary( }

IDL Example [ object,uuid( 5FBDD020-1863-11CF-9946-444553540000) ] interface IThesaurus : IUnknown { HRESULT Return Synonym( [in] OLECHAR word[31], [out] OLECHAR synonym[31] ); }

IDL Example [uuid( B253E460-1826-11CF-9946-444553540000), version(1.0)] library TextToolsLib { importlib (“stdole32.tlb”); B2ECFAA0-1827-11CF-9946-444553540000)] coclass CoTextTools { interface ISpellChecker; interface IThesaurus; }

Automation Making applications programmable Programmability through macro languages Cryptic No standard exists One choice for an application Automation General programmability with COM Use developer’s favorite programming tools to build applications on top of the functions already provided by existing software

Send electronic copies Automation Example Database E-mail Spreadsheet Word processor Charting Automation script: Extract current data Tabulate and sum Chart the results Place chart in report Send electronic copies of report to staff

IDispatch and dispinterfaces Client Invoke( ) { switch (DISPID) 1: MethodX( ); 2: MethodY( ); 3: MethodZ( ); } IDispatch:: Invoke(DISPID) IDispatch vtable Object dispinterface

Clients and Servers Application Client IDispatch Object IServices

dispinterfaces and Marshaling Using a dispinterface for marshaling requires only a single proxy and stub The parameters for a dispinterface method are packaged into a variant The client passes the variant along with the DISPID on the call to IDispatch::Invoke The object that implements the dispinterface unpackages the variant Results are wrapped in a variant by the object and then returned to and unwrapped by the client

A Visual Basic Example Sub SpellCheck( ) Dim Obj As Object Set Obj = CreateObject(“Excel.Application”) Word = InputBox(“Enter word”) If Obj.CheckSpelling(Word) Then MsgBox( “Valid word” ) Else MsgBox( “Word not found” ) End If End Sub

Dual Interfaces Client Object IDispatch:: Invoke(DISPID) dispinterface Invoke( ) { switch (DISPID) 1: MethodX( ); 2: MethodY( ); 3: MethodZ( ); } IDispatch:: Invoke(DISPID) vtable Object dispinterface

Dual Interfaces [object, uuid( E7CD0D00-1301-11CF- Interface ISpellChecker : IDispatch { import “unknown.idl”; import “oaidl.idl”; HRESULT LookUpWord([in] BSTR word, [out] boolean *found); HRESULT AddToDictionary( [in] BSTR word); HRESULT RemoveFromDictionary( }

Dual Interfaces [uuid( B623E460-1837-11CF-9946-444553540000), version(1.0)] library SpellCheckerLib { importlib (“stdole32.tlb”); B23EFAA0-1849-11CF-9946-444553540000)] coclass CoSpellChecker { interface ISpellChecker; }

Persistence and Monikers An object’s persistent data is information about the object’s state that’s saved between instantiations of the object A mechanism that lets objects store and retrieve their persistent data is called a persistence service An object’s client typically controls when the object’s persistent data is loaded and saved

Structured Storage Disk file Root storage (Compound file) Storage Stream

Using Structured Storage COM object Storage Stream Stream

Moniker A moniker is a name for a specific object instance, one particular combination of CLSID and persistent data A moniker is an object that supports the IMoniker interface Each moniker has its own persistent data, which contains everything the moniker needs to start and initialize the single object instance the moniker identifies

Using a Moniker Client Moniker Object Server 1 2 3 4 A IMoniker