OOMI A short introduction to Microsoft's Component Object Model (COM)

Ingeniørhøjskolen i Århus Slide 2 af 53 Agenda Goals of COM? COM History Programming COM servers Using COM servers –(client side programming) COM’s architechure

Ingeniørhøjskolen i Århus Slide 3 af 53 Goals of COM Binary encapsulation –Clients do not have to be re-compiled if server objects change Binary compatibility –Client and server objects can be developed with different development environments and in different languages Access & Location transparency –in-process –cross-process –cross-machine Zero sacrifice in-proc performance Simplest model possible –Enable extensibility and adaptability To provide a component object model that facilitates:

Ingeniørhøjskolen i Århus Slide 4 af 53 The COM Runtime COM is a proprietary Microsoft standard –But other companies have implemented COM on other platforms (e.g. Software AG on Unix) Highly debugged and tuned –The COM Runtime first shipped in 1993 –Used by 1000s of commercial applications DCOM first released in Windows NT 4.0, August 1996 –Win95 version released January 1997 COM/DCOM Available today on – Win95, Win98 and WinME – NT, Win2K and XP –Solaris, HPUX, Linux, MVS, VMS, Mac and others Free! (Built-into Win32 Platforms) –No separate client access license or expensive “developer” version Full source code licensable

Ingeniørhøjskolen i Århus Slide 5 af 53 COM History COM is some what tainted by its legacy

Ingeniørhøjskolen i Århus Slide 6 af 53 Destination The Clipboard and DDE The user produce some data in a source program and stores them on the clipboard. The user paste the date from the clipboard into the destination program. This process can be automated with DDE: –Dynamic Data Exchange –DDE is based on Windows Message system (and was a pain to program) –DDE is an old technology but is still used in some programs Source Clipboard The brown fox …

Ingeniørhøjskolen i Århus Slide 7 af bit OLE 1.0 Object Linking & Embedding 1.0 utilized the clipboard to copy not only the data, but also information about the data source. A user copying a graph would actually copy 3 pieces of information to the clipboard: –Presentation data –Class information –The raw data Copying the raw data created an embedded object Copying a file reference created a linked object Pasting the graph into e.g. a word document produced a compound document. OLE 1.0 used DDE as it’s interprocess communication mechanism.

Ingeniørhøjskolen i Århus Slide 8 af bit OLE 2.0 Object Linking & Embedding 2.0 was implemented using a new technology: COM –The Component Object Model - COM OLE 2.0 (COM) features: –Binary standard for objecs –Lifetime management –Structured storage –Inter-application drag and drop –In-place editing –OLE Automation The 16-bit Windows OS wasn’t really capable of all this – often available system resources went down to 0!

Ingeniørhøjskolen i Århus Slide 9 af 53 OLE Controls Visual Basic 3.0 had a mechanism for extending itself with custom controls: –Visual Basic Controls – VBX controls With Visual Basic 4.0 came an enhanced technology for custom controls: –OLE Controls - OCX controls An OCX characteristics –must be loaded into a container –Is implemented in a DLL –Exports COM interfaces So COM legacy is tied to VB amongst others

Ingeniørhøjskolen i Århus Slide 10 af bit OLE With the release of NT 3.51 (an shortly after Windows 95) came 32-bit OLE. 32-bit OLE used some NT features like Unicode strings, but lacked others like NT security. The inter-process infrastructure was build on MS- RPC (Remote Procedure Call)

Ingeniørhøjskolen i Århus Slide 11 af 53 ActiveX Before the release of NT 4.0 MS announced Network OLE, but the press called it OLE 3.0, so MS dropt the name OLE, and just called it COM and DCOM. But only for a short time –When the Internet reached Microsoft the came up with a new name: ActiveX ActiveX Controls are light weight OLE Controls and can be used on Web pages. DCOM first released in Windows NT 4.0, August 1996

Ingeniørhøjskolen i Århus Slide 12 af 53 ActiveX Builds on COM COM’s initial thrust: –integrating desktop applications with OLE COM technology is generically useful, being applied to a range of other areas –Inherently distributed So What is ActiveX? –A marketing name for a set of technologies and services, all based on COM

Ingeniørhøjskolen i Århus Slide 13 af 53 Active Components ActiveX Controls –Are COM components –Have “design-time” UI called property page(s) –Implements MS defined standard interfaces –Must have automation/dual interface –Supports events –Can be written in C++, Java, VB, Delphi,... –Self-registering –Optimized for download and execute Work on both Active Client or Server –Can talk indirectly over HTTP or directly over COM

Ingeniørhøjskolen i Århus Slide 14 af 53 Microsoft Transaction Server Microsoft® Transaction Server (MTS) was introduced at the PDC in Long Beach in 1996 Runtime execution environment for server- based components Extends COM archi- tecture with transaction semantics Provides concurrency, multi-threading, queuing, atomicity, etc. Makes is easy to encapsulate business logic in middle-tier

Ingeniørhøjskolen i Århus Slide 15 af 53 COM/DCOM/OLE Architecture In-Place Activation LinkingEmbedding Drag and Drop Uniform Data Transfer ActiveX Controls Persistent Objects Structured Storage Component Object Model, Distributed Component Model Monikers Events Property Pages Property Change Notification Automation Connectable Objects Type Information Brockschmidt, Kraig, Inside OLE [Microsoft Press]

Ingeniørhøjskolen i Århus Slide 16 af 53 What Is COM+? Unification of COM and MTS Plus... –Extensions to base COM –Extensions to MTS services –New Services Minimal impact on how you write components Remoting architecture doesn’t change (DCOM)

Ingeniørhøjskolen i Århus Slide 17 af 53 COM+ Strategy Transactions Data Binding Persistence Load Balancing Security In Memory Database Event Infrastructure Ubiquitous Type Description Dynamic Invocation “No-Leak” Memory Mgmt Interception Tools Ubiquity Market Binary Standard

Ingeniørhøjskolen i Århus Slide 18 af 53 COM+ Philosophy Attribute-based Programming –Write your Logic –Add Annotations (Set Attributes) –The Runtime Does all the Grungy Stuff –Interceptors Can Add Value Later

Ingeniørhøjskolen i Århus Slide 19 af 53 Making it easy System provided implementations of –IUnknown AddRef / Release QI –Class factory –DLLRegisterServer, DllUnregisterServer, DllLockServer –IDL –TypeInfo –IDispatch –IConnectionPoint, IConnectionPointContainer –IProvideClassInfo –IPersist*

Ingeniørhøjskolen i Århus Slide 20 af 53 Future of COM COM & DCOM may still have a place – especially COM as an Component architecture – not as Distributed Middleware.NET Remoting & Web services is a threat to DCOM But know back to business

Ingeniørhøjskolen i Århus Slide 21 af 53 Programming COM servers Classes & Interfaces in C++ #define interface struct // The interface. interface ICar { virtual void SpeedUp(long delta) = 0; virtual void CurrentSpeed(long *currSp) = 0; }; // The basic Car. class Car : public ICar { private: long m_currSpeed; public: // ICar implementation. void SpeedUp(long delta) { m_currSpeed += delta; } … }; void main() { // An array of ICar interfaces. ICar* theCars[2]; theCars[0] = new Car(); theCars[1] = new HotRod(); … theCars[i]->SpeedUp(10);

Ingeniørhøjskolen i Århus Slide 22 af 53 COM is not C++ objects COM is an Component Model And as as such is very different from C++ –The Binary component makes the difference –Implemented as a DLL or an EXE (Service or stand alone)

Ingeniørhøjskolen i Århus Slide 23 af 53 The Composition of a COM DLL Mandatory interface coclass Class factory also called class object Standard interface Custom interface Global functions (normal extern C)

Ingeniørhøjskolen i Århus Slide 24 af 53 Interface A group of related functions that specifies a contract –name, interface signature, semantics, and marshaling buffer format Denotes behavior only, not state Identified by a GUID – Global Unique Identifier –Called IID – Interface ID Must derive from IUnknown –either directly or through other interfaces

Ingeniørhøjskolen i Århus Slide 25 af 53 Microsoft IDL (MIDL) Language for expressing all COM concepts Like OMG’s CORBA IDL … MIDL is –programming-language independent –evolved from OSF/RPC IDL –not computationally complete but better than C++ header files In COM IDL files are compiled with a MIDL compiler It is NOT the same as CORBA IDL

Ingeniørhøjskolen i Århus Slide 26 af 53 MIDL output RawComCar.idl Midl.exe RawComCar.h Contains C and C++ definitions for each COM type RawComCar_i.c Contains the GUIDs for each COM type RawComCar.tlb Binary IDL primarily for non C/C++ clients RawComCar_p.c dlldata.c Files used to build a custom stub and proxy DLL to marshal your COM interfaces

Ingeniørhøjskolen i Århus Slide 27 af 53 // RawComCar.idl import "oaidl.idl"; // The ICar interface [uuid(710D2F f66-9F64-201D56FB66C7), object] interface ICar : IUnknown { HRESULT SpeedUp([in] long delta); HRESULT CurrentSpeed([out, retval] long* currSp); }; COM Interfaces in MIDL IID (interface identifkation) Interface Root Interface Items in square brackets are called attributes. ( attributes in COM are not related to attributes in UML)

Ingeniørhøjskolen i Århus Slide 28 af 53 GUID A GUID is a 128-bit number that is statically unique GUID’s are used to identify severel different COM subjects, e.g. interface IID, coclass CLSID … Can be created by a tool or programmatically Wtypes.h has many defines ease working with GUIDs, Ex: #define REFGUID const GUID * const #define REFIID comst IID * const And objbase.h has some helper functions and operator overloads

Ingeniørhøjskolen i Århus Slide 29 af 53 COM Class ~ coclass Named, concrete implementation of one or more interfaces Identified by a CLSID (~ GUID) –sometimes ProgID too Type libraries may describe incoming, outgoing interfaces

Ingeniørhøjskolen i Århus Slide 30 af 53 COM Class in MIDL // RawComCar.idl // The Raw Car Library. [uuid(D679F136-19C B229-F338AE163656), // Library ID (LIBID) version(1.0),] library RawComCarLib { importlib("stdole32.tlb"); // Our COM class. [uuid(096AC71D-3EB A071-A3B1C0B7FC8D)] // Class ID (CLSID) coclass ComCar { [default] interface ICar; interface IRadio; }; // an other COM class. [uuid(7AD9AFC9-771C-495c-A D54A23650)] // Class ID (CLSID) coclass ScriptableCar { [default] interface IScriptableCar; };

Ingeniørhøjskolen i Århus Slide 31 af 53 Implementing the COMCar // ComCar.h: interface for the ComCar class. #include // MIDL generated file! #include "rawcomcar.h" // ComCar implements IUnknown, ICar and IRadio. class ComCar : public ICar, public IRadio { public: ComCar(); virtual ~ComCar(); // IUnknown impl. STDMETHOD_(ULONG,AddRef)(); STDMETHOD_(ULONG,Release)(); STDMETHOD (QueryInterface)(REFIID riid, void**); // ICar impl. STDMETHOD (SpeedUp)(long delta); STDMETHOD (CurrentSpeed)(long* currSp); // IRadio impl. STDMETHOD (CrankTunes)(); // data members ULONG m_refCount; // Ref counter. long m_currSpeed; // Current speed! };

Ingeniørhøjskolen i Århus Slide 32 af 53 ComCar’s implementation of IUnknown STDMETHODIMP_(ULONG) ComCar::AddRef() { return ++m_refCount; } STDMETHODIMP_(ULONG) ComCar::Release() { if(--m_refCount == 0) delete this; return m_refCount; } STDMETHODIMP ComCar::QueryInterface(REFIID riid, void** ppInterface) { // Remember! Always AddRef() when handing out an interface. if(riid == IID_ICar) { *ppInterface = (ICar*)this; ((IUnknown*)(*ppInterface ))->AddRef(); return S_OK; } … }

Ingeniørhøjskolen i Århus Slide 33 af 53 All this not necessary The above code is not necessary Use ATL COM Wizards in MS VS

Ingeniørhøjskolen i Århus Slide 34 af 53 Objects vs. Components COM Object –an instance of a COM Class COM Component –binary unit of code that creates COM objects –includes packaging code, registration code, class factory, etc.

Ingeniørhøjskolen i Århus Slide 35 af 53 COM: Objects Instances of COM Implementations References to COM objects are called interface pointers Interface pointers refer to main memory locations References support location transparency Object references are persistent

Ingeniørhøjskolen i Århus Slide 36 af 53 COM Classes Named implementations Have one or several interfaces Are the principal mechanism to create COM objects Can return interface pointers to specific COM objects

Ingeniørhøjskolen i Århus Slide 37 af 53 implements 1..* Interface uuid : GUID implements instantiates 0..* 1 Implementation 1..* instantiates 11 Class clsid : GUID 1..* 0..* Object location : int 0..* 1 creates&locates ClassObject * COM Objects, Interfaces and Classes

Ingeniørhøjskolen i Århus Slide 38 af 53 UML: Attributes COM does support UML attributes (state information) Attributes must be represented as set and get operations by the designer COM has a keyword to designate this: Property –propget –propput Example: interface IOrganization : IUnknown { [propget] HRESULT Name([out] BSTR val); }; interface IOrganization : IUnknown { [propget] HRESULT Name([out] BSTR val); };

Ingeniørhøjskolen i Århus Slide 39 af 53 COM: Operations interface IClub : IOrganization { [propget] HRESULT NoOfMembers([out] short *val); [propget] HRESULT Address([out] ADDRESS *val); [propget] HRESULT Teams([in] long cMax, [out] long *pcAct, [out,size_is(cMax),length_is(*pcAct)] ITeam *val); [propput] HRESULT Teams([in] long cElems, [in,size_is(cElems)] ITeam *val); [propget] HRESULT Trainers([out] ITrainer *val[3]); [propput] HRESULT Trainers([in] ITrainer *val[3]); HRESULT transfer([in] IPlayer *p); }; Operation name Parameter list Parameter kind Return value indicating success/failure Parameter, e.g. Interface pointer

Ingeniørhøjskolen i Århus Slide 40 af COM: HRESULTS HRESULTS are 32-bit integers Structured into four fields Severity Code Reserved Facility Code Information Code

Ingeniørhøjskolen i Århus Slide 41 af 53 COM Operation Invocations Invocation is defined by client objects Invocation determines –Interface pointer of server object –Name of invoked operation –Actual parameters Invocation is executed synchronously Invocation can be defined –statically –dynamically Clients have to interpret HRESULTS!

Ingeniørhøjskolen i Århus Slide 42 af 53 COM Architecture The Model The “ORB” The Services

Ingeniørhøjskolen i Århus Slide 43 af 53 COM Principles Rigorous Encapsulation –Black box -- no leakage of implementation details –All object manipulation through strict interfaces Polymorphism –via multiple interfaces per class –“Discoverable”: QueryInterface COM Object IUnknown IRobot IDispatch

Ingeniørhøjskolen i Århus Slide 44 af 53 COM Architecture: In process In process Once COM connects client and object, the client and object communicate directly without added overhead COMRuntime Component Client Server

Ingeniørhøjskolen i Århus Slide 45 af 53 COM Architecture: Local Out of process - Local LPC COM run time provider Security RPC RPC COM run time Security provider RPC RPC Component Client Server

Ingeniørhøjskolen i Århus Slide 46 af 53 COM Architecture: Out of process - Remote Out of process -Remote Out of process - Remote Protocol stack DCOM network- protocol COM run time providerSecurity RPC RPC COM run time Securityprovider RPC RPC Component Client Server

Ingeniørhøjskolen i Århus Slide 47 af 53 COM Architecture Clients always call in-process code; objects are always called by in-process code. COM provides the underlying transparent RPC.

Ingeniørhøjskolen i Århus Slide 48 af 53 The COM “ORB” The “model” is about how the technology is used The “ORB” is how it’s implemented In COM the ORB is called the COM Runtime

Ingeniørhøjskolen i Århus Slide 49 af 53 Structure of the COM “ORB” The COM Runtime COM and Distributed COM Registry Pluggable Security (SSPI) NTLM Kerberos Pluggable Transports DCE MS-RPC TCPUDPIPXSPXHTTP“Falcon” ETC... Core Services (Automation, Monikers, Storage, ComCat, Data Transfer, IR) Components and Applications

Ingeniørhøjskolen i Århus Slide 50 af 53 Architecture Object Proxy COM Library Interface proxy Client Object stub COM Library Interface stub SCM Registry SCM Registry OXID Resolver OXID Resolver MicrosoftRPCs OXID Object Application Layer Presentation Layer Session Layer Server Implementation COM Class OXID: object exporter identifier – associates RPC bindings to objects SCM: Service control manager – activates remote objects

Ingeniørhøjskolen i Århus Slide 51 af 53 Core COM Services Security Lifecycle Management Type Information (Interface Repository) Monikers (Naming) Automation (Dynamic Invocation) Data Transfer Component Categories Registry

Ingeniørhøjskolen i Århus Slide 52 af 53 Recommended Books “Essential COM” Don Box, Addison-Wesley “Inside COM” Dale Rogerson, Microsoft Press “Professional DCOM” Roger Grimes, Wrox Press “Component Software” Clemens Szyperski, Addison-Wesley

Ingeniørhøjskolen i Århus Slide 53 af 53 MSDN Library Resources COM Specification COM Programmer’s Cookbook Designing COM Interfaces COM Home Page