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
IDownloader = interface
procedure GetFile (FileName);
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.
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.
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.