COMCOM omponent bject odel After this presentation, you will: Be Able To: Conceptual understanding of COM How it works, What it’s used for Decode Acronyms (COM, DCOM, MTS) Know where to go, what to do, next Not Be Able To: Start programming COM (find a technical tutorial for that)

“Framework for runtime objects” OOP, plus ways of interacting with the objects at runtime Need to be able to create, inspect, use, destroy them In order to use them, must be able to ask them about what they do, ask them to do things Extensible: doesn’t require any more changes to COM itself (i.e., there is no COM 2.0, 3.0,etc) Versioning: figuring out which version of an object you want (at runtime) Language independent: Strongly influenced by C++, but usable in C, VB, Java, plus anything else that you want to do the work for (Python?) Middleware – doesn’t really do any app. level work, but provides the ‘pipes’ for app.s to do work Some Cool Features:

History: Started with OLE 1.0: Object Linking and Embedding, or “How do I drop an Excel spreadsheet into Word?” Worked, but badly, OLE didn’t look like COM OLE 2.0: OLE built over COM, and so version number stops here ActiveX: COM is cool, but the Internet showed up, MS wrote up a collection of COM stuff specifically oriented at Internet use: how to download, sign, install COM objects. Thus, COM is the framework/architecture/infrastructure over which OLE (business stuff), and ActiveX (Internet stuff) is built

Example of a COM session CRandom Server Client Server supports the creation of random numbers, Client wants a random number 1) Client creates an instance of CRandom (via CoCreateInstance system call) COM 2) COM locates the server, if not already running, COM starts it, asks server to create an instance of CRandom 3) CRandom server creates an instance of CRandom, and hands a pointer back to the client Newly Created object

Example of a COM session (con’t) CRandom Server 4) Client can interrogate the object about what it can do, then invoke methods on the object. Client 5) Client finishes using the object, then calls the Release method to tell the object that the client is finish. 6) At this point, the object deletes itself, and the server figures out if it can be unloaded. If so, either it or COM unloads it from memory. CRandom object

More Technical Overview: Phases: Location: How to name objects, how does COM know where the servers are to be found? Creation: How does one create individual instances of an object? Communication: How do the objects talk to each other in a standard way? Teardown: How to manage destruction, especially since multiple client may be using the same object simultaneously?

Naming Objects: Decentralized, guaranteed to be unique names UUID: Universally Unique IDentifier GUID: Globally Unique Identifier Guidgen tool is provided to make these for you. How does COM Locate stuff? Registry: an OS level DB that holds (among other things) locations of code info about the code, etc Location Phase:

Once request to create the object has been given to COM, and it’s figured out where the object server is, it starts the server (if it hasn’t been started yet), and asks it to create another instance of the object via…. Class Factory: Another COM class, except that it has no GUID associated with it (uses the GUID of the object it creates), responsible for creating new objects. Note that this process differs in different languages (e.g., C++ vs. C). Since whoever writes the COM server also writes the Class Factory, this also gives some power in being able to control how objects are created -- could create a single instance & share among the clients, or create lots and lots, etc. Creation Phase:

Interfaces: All communication between clients and objects are done through INTERFACES. To the client, calling any method on any object is exactly the same, except for arguments and return values. Thus there is a standard way of getting clients to communicate with objects. Every interface derives from IUnknown, which contains three methods: QueryInterface: Does object support interface X? AddRef: Tell object that something else is using interface Release: Tell object that something is finished using interface Code to marshal arguments between client and object may be needed (e.g., cross process) Communication Phase:

How does COM know when to deallocate stuff? It doesn’t -- the objects themselves know, by keeping a reference count of clients. Each time a client asks for an interface (or calls AddRef), this count gets bumped up. Each time the client calls the Release() method on an interface, the reference count get decremented. When the reference count is zero, the object can deallocate itself (i.e., delete this; ) Recurrent theme objects keep refcounts to know when to deallocate, object servers keep reference counts on number of outstanding objects to know when they can be shut down Within the IClassFactory interface, the LockServer method keeps a reference count so that the object server WON’T shut down, etc Teardown Phase:

Containment/Aggregation – inheritance Threading -- couple of different threading models IDispatch Run time use of interfaces & methods Used by interpreted/macro languages (Java, VB) so they don’t have to recompile to use a new interface Uses Type Libraries, which contain descriptions of methods, the arguments, etc Other Issues:

DCOM (Distributed COM) How to instantiate / use components residing on different computers? Also needs to worry about security, more efficient ways of asking about interfaces, etc MTS (MS Transaction Server ) Runtime environment layered over DCOM to support scalable, fault tolerant apps COM+ (not yet released) Runtime environment, makes it easier to use COM Beyond that, ??? Recent Developments

Books Inside COM Professional DCOM programming Essential COM My Web page mwp3/COM_Tutorial/index.html MS web site Mailing lists Each other in Quintet– ask around! Further References, Resources: