Events/Callbacks

Once you've understood interfaces, objects, servers, that's where the fun starts! For instance, all this time we've talked about clients talking to servers - it has always been one way: a client, a server, and the client talks to the server. Wouldn't it be more adventurous if the server also talked back to the client. You might ask "Why the heck would a server  want to talk back to a client?" To complain if it gets abused?

Well, not quite! Consider a simple scenario: You are creating an application that downloads album tracks from the web to allow people to sample some music before they buy an entire album. Since downloading web content is generic functionality (i.e. you can download files, audio clips, pictures, etc.) and can possibly be used by other applications you develop in the future, you decide to create a separate COM object object that does the downloading - let's call this object Downloader. Downloader exposes an IDownloader interface that has a GetFile method:

IDownloader = interface
  procedure GetFile (FileName);
end;

You then go ahead and implement Downloader.GetFile and use it from your client application. Later on, you realize that downloading a 5MB+ music track from the web can be a pain-in-the-ass process especially if you have a lame internet connection because you have to wait for a long time for the download to complete. Being the smart developer that you are, you think "Well if I can just see the progress of the download using a percent complete or a progress bar mechanism, that would make things a lot better!" That's a very good idea!

A common-sense way to implement this progress mechanism is by making the IDownloader.GetFile method notify the client at regular progress intervals during the download. Did you read that? "Notify the client!" That's analogous to "talk to the client"! Now, this is one example of why an object may want to talk back to its client.

In COM, the process of a server talking back to the client is commonly referred to as callbacks or events . Event mechanisms can open up interesting options for your applications. For instance, events can be used to notify clients of data changes on the server end. Events can also be used by servers that are "monitors" to notify the client of any changes in the state of the entity that the server monitors.

Let us then take a look at what's involved in implementing events:

Basic Event Concepts

Events really aren't that hard to implement in COM. In fact, if you have a good understanding of interfaces and objects, you should be able to use that knowledge to implement events.

Connection Points

Since event mechanisms are a common necessity, COM provides a structured mechanism for implementing events. This mechanism is so widely used today that it would be foolish not to learn how it works.

Publisher/Subscriber Mechanism

Expanding on the implementation techniques, COM+ introduces a "new and improved" structured mechanism for handling events. This mechanism is very interesting and is very useful in contexts where Connection Points (and other techniques) are simply not applicable.