DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


Chapter 3
Main Concepts Used in DCOM

  Globally Unique Identifier
  Classes, Objects, and Components
  Class IDs
  Interfaces
  Polymorphism and Encapsulation
  Inheritance
  Interface Containment and Aggregation
  IUnkonwn
  Monikers

All Object Request Brokers (ORB) conforming to CORBA use the same conceptual model. Microsoft’s model of object-based processing—COM—is, however, different, and it is worthwhile understanding the concepts Microsoft uses, as it affects the capabilities of DCOM and the sorts of application a developer can build.

Thus, although it is not, strictly speaking, essential that the developer has a detailed grasp of the concepts used in COM, a basic understanding helps in any discussion. This chapter thus provides a brief overview of the main concepts used.

We will be introducing other concepts such as Outgoing Interfaces, IDispatch, and all other terms in the context of the functions they provide. The terms you see here are the basic building blocks on which everything in COM is based.

GUID

GUIDs are Globally Unique Identifiers for things. The things in question can be anything—interfaces, classes/components, programs, and so on, but within DCOM they are used specifically for classes and interfaces. The important point about a GUID is that it is unique, whereas a name (however long) may not be. The number used is a 128 bit/16 byte value which is created automatically by DCOM services. Microsoft’s GUIDGEN.EXE and UUIDGEN.EXE both automatically generate GUIDs.

Different mechanisms can be used to create the identifier so that it is unique, but the one most commonly employed uses a combination of the IEEE machine identifier of the host used to create the thing, (this is obtained from the network card and subsequently has no meaning), the date/time of creation (to nanosecond level), plus, if need be, an incremental counter. The resulting GUID then has the sort of format shown below:

00000001-0000-0000-C000-000000000045

The resulting number has no meaning, but the use of the network card number ensures that the resulting number is unique. For systems without network cards, other algorithms are used to generate the value.

GUIDs are the same as the UUIDs (Universal Unique Identifiers) used by the OSF (Open Software Foundation—now the Open Group) when they developed DCE (Distributed Computing Environment). We will be learning more about DCE in a later chapter.

Programmers do have to know about GUIDs, but in their programs they do not have to use them directly—they can use the names of things, which are then cross-referenced within their programs to the GUIDs themselves. We will be seeing later how this works. But DCOM doesn’t use names at all; it relies entirely on GUIDs because of the need for uniqueness (especially in a cross-company or even intercompany context).

Classes, Objects, and Components

Anyone used to object programming will know already that the basis of this paradigm of processing is some “thing” which is identified by the methods or functions it supports. So, we might have a customer “thing” with functions which “update the customer name,” “query the address,” “calculate the credit limit,” and so on. Each method has parameters input and output to the method in much the same way we might make a subroutine call in a conventional program. So, one obvious example may be the method “update customer name” with an input parameter of the customer’s new name.

A component is the generic name given by Microsoft to this type of thing and its methods. A class is a block of machine code based around some concept and which has methods which can be invoked.


Figure 3.1  The customer component with its methods and parameters

In practice, component and class tend to be used almost interchangeably by developers because for each component there is one class. The main difference is that the term component is used for the thing throughout its life—from design concept to source code to machine code. Class refers to the component at a certain point in this cycle—when it becomes machine code.

Microsoft also defines a class as “a particular implementation of certain interfaces,” which means that theoretically you have to know what the interfaces are before you can define a class. Classes are executable blocks of machine code (or interpretable code), as opposed to source code—thus the use of the term “implementation” in its definition.

Machine resident blocks of code are called objects. An object is thus a single binary version of a component which has been compiled for that platform, which runs on that platform and that can be found in an actual DLL or EXE file. The word class is thus used as a generic term for an executable block of code implementing a set of defined interfaces. The occurrences of those blocks of code are termed objects. Objects are usually given the same class name and class identifier to show they are effectively the same “thing.”

Thus in COM, the most important concept is actually the class rather than the object or, for that matter, the component. Developers know of the existence of classes, not their implementations in files or libraries.

CLSID

The Class ID (CLSID) is the identifier of the class. CLSIDs are in effect GUIDs—unique global identifiers used to identify the class—and are generated in exactly the same way as GUIDs. Not all classes need a CLSID. Only classes that need to be invoked from external processes need to be identified.


Previous Table of Contents Next