A typical COM object

[sukishan]

Now let's put all of these new concepts together and describe a typical COM object and a program that wants to access it. In the next section and the following chapters we will make this real by implementing the actual code for the object.

Imagine that you want to create the simplest possible COM object. This object will support a single interface, and that interface will contain a single function. The purpose of the function is also extremely simple - it beeps. When a programmer creates this COM object and calls the member function in the single interface the object supports, the machine on which the COM object exists will beep. Let's further imagine that you want to run this COM object on one machine, but call it from another over the network.

Here are the things you need to do to create this simple COM object:

*You need to create the COM object and give it a name. This object will be implemented inside a COM server that is aware of this object.
* You need to define the interface and give it a name.
* You need to define the function in the interface and give it a name.
* You'll need to install the COM server.

For this example, let's call the COM object Beeper, the interface IBeep and the function Beep. One problem you immediately run into in naming these objects is the fact that all machines in the COM universe are allowed to support multiple COM servers, each containing one or more COM objects, with each COM object implementing one or more interfaces. These servers are created by a variety of programmers, and there is nothing to stop the programmers from choosing identical names.

In the same way, COM objects are exposing one or more named interfaces, again created by multiple programmers who could randomly choose identical names. Something must be done to prevent name collision, or things could get very confusing. The concept of a GUID, or a Globally Unique IDentifier, solves the "how do we keep all of these names unique" problem.