1. Component Object Model (COM) A short introduction
OOMI
Component Object Model (COM)
A short introduction

2. Agenda Goals of COM COM History Programming COM servers & clients
COM’s architechure & runtime
We will NOT cover DCOM in this presentation – only introduce COM. Next time DCOM.

3. Goals of COM To provide a component object model that facilitates:
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
Almost exactly what the .NET Frameworks handles
Microsoft recommends -> use .NET not COM
Is still a major part of Win32 operating systems incl. .NET

4. 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 (and apparently also Win CE)
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

5. COM History COM is some what tainted by its legacy
16 bit OLE 1.0: for advanced clipboard (replacing DDE)
16 bit OLE 2.0: more advanced -> introducing COM
Visual Basic VBX: for extending Visual Basic with e.g. C++ and other components -> later OCX
OLE Controls (OCX): container implemented in DLL
32-bit OLE: NT 3.51 (an shortly after Windows 95). An inter-process infrastructure was build on MS-RPC
Network-OLE: pre NT 4.0 (name dropped)
COM & DCOM: NT 4.0
ActiveX: light weight OLE Controls for e.g. Web pages. Can be written in C++, Delphi, VB
COM+: Finally step of COM

6. COM+ Strategy Services Runtime COM
COM+ is Unification of COM and MTS + new services and extensions
Foundation for the .NET Enterprise Services (up-and-comming=
Transactions
Data Binding
Persistence
Load Balancing
Security
In Memory Database
Event Infrastructure
Services
Ubiquitous Type
Description
Dynamic Invocation
“No-Leak” Memory Mgmt
Interception
Runtime
Tools
Ubiquity Market
Binary Standard
COM
Main point: The strategy for COM+ is to build on the tremendous success of COM, while providing the ability to develop more productively. This is accomplished by putting more of the infrastructure in the system, so that developers will have to write less object infrastructure code themselves. Providing a rich runtime environment which optionally hides tricky issues such as reference counting from developers essentially provides the best of all possible worlds.
Attribute-based Programming
Write your Logic
Add Annotations (Set Attributes)
The Runtime Does all the Grungy Stuff

7. COM is not C++ objects COM is a Component Model
Distributed middleware features are only spin-off
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)
Like CORBA it uses an IDL language for decoupling (MIDL)
A descendent of RPC/IDL with extensions

8. COM Component Principles
Rigorous Encapsulation
Black box -- no leakage of implementation details
All object manipulation through strict interfaces
Polymorphism
via multiple interfaces per class
“Discoverable”: QueryInterface
IUnknown
IDispatch
COM Object
IRobot

9. COM vocabulary COM Interfaces (= interface) COM Classes (= coclass)
The interface definition, behavior only, no state
A group of related functions that specifies a contract
Must derive from IUnknown or descendents hereof
COM Classes (= coclass)
The implementation of one or more interfaces
Returns the interface pointers to specific COM Objects
Object references are persistent
COM Object
an instance of a COM Class
COM Component
binary unit of code that creates COM objects
A DLL or an EXE
includes packaging code , registration code, class factory, etc.
No references
Pointers are used – both locally AND remote (pointer to proxy)

10. The Composition of a COM DLL
Global functions
(normal extern C)
Mandatory interface
Class factory also called class object
Standard interface
coclass
Custom interface

11. 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
Using toolkits (such as ATL) this is done automatically
Used both with IID and CLID
Interface ID (IID) Class ID (CLID)

12. 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
Contains both interfaces and coclasses

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

14. Will be continued later …
COM Interfaces in MIDL
// 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); };
Will be continued later …
IID
(interface
identification
- GUID)
Items in square brackets are called attributes. (attributes in COM are not related to attributes in UML)
Interface
Root Interface
Method

15. Continued from interface part
COM Class in MIDL
// RawComCar.idl continued from the “interface part”
[uuid(D679F136-19C B229-F338AE163656),
version(1.0)]
library RawComCarLib {
// 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;
Continued from interface part

16. Implementing the COMCar coclass
// ComCar.h: interface for the ComCar class.
#include <windows.h>
// 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! };
Like CORBA & Java – must implement the interface in a class

17. 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; …
Always pr. interface:
::AddRef,
::Release &
::QueryInterface MUST
be implemented for each
Returns a pointer to “this”
The above code is not necessary
Use ATL COM Wizards in MS VS

18. Client Implementation
CoCreateInstance
searches the registry
for the right CLSID entry,
decides if in-process (DLL),
out-of-process (EXE) or
on another machine, creates
the class factory, queries for IID_ICar,
and returns a pointer to proxy (or direct)
void SomeFunction () {
ICar *pcar;
HRESULT hr;
hr = CoCreateInstance(CLSID_ComCar,
NULL,
CLSCTX_SERVER, IID_ICar,
&pcar);
pcar-> SpeedUp(5);
pcar- ->Release(); }
Method calls
Call the method on pcar and release
CoInitialize
We have initialize the
runtime at some point in time
before calling CoCreateInstance
// Initialize COM
hr = CoInitialize(NULL);

19. Implementation Three ways of implementing COM Components
Manually (use MIDL, code implementation classes)
Must make MIDL and compile
Must code implementation of IUnknown and own interfaces
Must register server
Considered extremely timeconsuming and error-prone
ATL Programming (MS solution to the above)
ATL: Active Template Library
ATL Wizards handles most of the nasty stuff for you
Including MIDL definition and compilation + regsitration
ATL code is very non-transparent!
Attributed Programming (with ATL)
See
rationalizes description of components, description kept in one place (near the implementation and not over several files)
generate code – no MIDL seen

20. 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!

21. In-process (DLL) – calls are made directly with no overhead
COM Architecture
In-process (DLL) – calls are made directly with no overhead
Out—of-process – but local (EXE) – calls are made using a light-weight RPC and stubs.
Clients always call in-process code; objects are always called by in-process code. COM provides the underlying transparent RPC.
Real RPC is used for
Remote Server Process
The Service Control Manger activates the server objects (uses the Registry) as requested

22. Structure of the COM Runtime (“ORB”)
Components and Applications
The COM Runtime
Core Services (Automation, Monikers, Storage, ComCat, Data Transfer, IR)
COM and Distributed COM
Registry
Pluggable Security (SSPI)
MS-RPC
Pluggable Transports
NTLM
DCE
Kerberos
ETC...
TCP
UDP
IPX
SPX
HTTP
“Falcon”

23. Core COM Services Security Lifecycle Management
Type Information (Interface Repository)
Monikers (Naming)
Automation (Dynamic Invocation)
Data Transfer
Component Categories
Registry