Every COM class has a unique Class Identifier, or CLSID, that is an instance of a 128-bit Globally Unique Identifier (GUID). The CLSID associates a COM class with the executable code that implements it. When you register your component with an operating system, you create a link between the CLSID and its associated .dll or .exe file. An application uses a CLSID to request the services of a COM object, obtaining a pointer to a class object that links interfaces to executable code. In a similar fashion, a client requests a pointer to a given interface by using a GUID known as the Interface Identifier, or IID.
A text-based component identification system can easily produce conflicts—for example, when two developers use the same name for different components or interfaces—but with GUIDs, two COM classes that have the same name will be identified by different CLSIDs. CLSIDs are also compact, using only 16 bytes, whereas text-based names can get rather long, confusing, and unwieldy.
The Windows API function CoCreateGUID generates what is guaranteed to be a globally unique GUID; this means you don’t need to worry that you might duplicate an identifier used by someone else. As a Java developer, though, you probably won’t be calling CoCreateGUID directly; Microsoft’s wizards will obtain and assign CLSIDs and IIDs for you. And because there are more than 3.4 × 1038 possible GUIDs, this function could theoretically identify more unique software components than could be implemented in the lifetime of the known universe!
When you register a COM object, you tell the operating system which CLSID is associated with which .dll or .exe file. Microsoft Windows maintains this information in its registry database, under the HKEY_CLASSES_ROOT hierarchy. In Chapter 7, when I produce a COM-compliant Java class, you’ll see how a component makes the operating system aware of its existence.