Page #107 (Chapter 10. Events)

< BACK  NEXT >

[oR]

Introduction

Notifying interested parties of changes to data is a very common requirement under distributed computing. A stock ticker program needs to notify clients with a change in stock price; a computer monitoring program needs to inform the administrators of the status of the system; a virus detection program needs to warn the computer user if a virus is detected; a medical monitoring program needs to page a doctor if a patient requires immediate attention, and so on.

Instead of referring to the interested parties as clients, we will use a different terminology. We will call them subscribers; programs that are interested in receiving information. Likewise, programs that provide such information will be referred to as publishers. As we will see shortly, when a publisher notifies a subscriber of a change in some data, the traditional role of a COM client and a COM server reverses temporarily; the COM client becomes a COM server and the COM server becomes a COM client. Using the terms publishers and subscribers will keep us sane.

So the publisher detects the changes the subscriber is interested in, but how does the subscriber find out from the publisher when a change takes place? The simplest approach is for the subscriber to poll the publisher every so often, similar to you refreshing a web page periodically to get the latest stock quotes. Under COM terminology, the subscriber would obtain an interface from the publisher object and periodically call a method on that interface to see if any changes had taken place. The following code illustrates this approach:

 while(true) {   bool bMarketClosed = spStockWatcher->IsMarketClosed();    if (bMarketClosed) {     break; // time for dinner.    }    currentQuote = spStockWatcher->GetQuote("MSFT");    ...  } 

Such polling interaction between a subscriber and a publisher is depicted in Figure 10.1.

Figure 10.1. Subscriber polls for data.

While this strategy is simple to implement, it is a terrible idea for several reasons:

• Inefficient resource utilization: If the data doesn t change that often, the subscriber wastes an enormous amount of CPU cycles asking for the same data and the publisher wastes enormous time replying with the same answer. Even worse is wasting network bandwidth when the publisher resides on a remote machine possibly on the other side of the country.

• Time lag between the occurrence of the event and the receiving of data: Polling involves some inevitable amount of latency between the time the change occurs and the time the subscriber gets around to polling for it. This latency is non-deterministic it varies from one occurrence to another.

A better approach would be for the publisher to initiate the notification process when it detects the data has changed. Instead of you refreshing the stock quote web page periodically, let the changed data come to you.

Under COM terminology, a publisher-initiated notification process is referred to as firing an event.

COM offers various degrees of support to implement firing and receiving an event. You choose a technique depending upon your needs.

We need a simple example to demonstrate these techniques. Our example will be a component that provides updated stock prices to interested applications. ^[1]

^[1] Almost all of the examples ever published on COM/COM+ events seem to deal with changes in stock prices. This leads me to believe that developers seem to understand the movement in stock prices better than any other changes.

Let s start dissecting these techniques!

< BACK  NEXT >