Generating events under COM

Many COM-based technologies, such as the ActiveX scripting engine and ActiveX controls, use event sinks and COM's connection point interfaces to generate events. Event sinks and connection points are examples of a tightly coupled event model. In such a model, applications that generate events (called publishers in COM+ terminology, and sinks in previous COM terminology) are aware of those applications that respond to events (called subscribers), and vice versa. The lifetime of publishers and subscribers coincides; they must be active at the same time. The collection of subscribers, and the mechanism that notifies them when events occur, must be maintained and implemented in the publisher.

COM+ introduces a new system for managing events. Instead of burdening each publisher with the management and notification of each subscriber, the underlying system (COM+) steps in and takes over this process. The COM+ Events model is loosely coupled, allowing publishers and subscribers to be developed, deployed, and activated independently of each other.

Although the COM+ event model greatly simplifies communication between publishers and subscribers, it also introduces some additional administrative tasks to manage the new layer of software that now exists between them. Information on events and subscribers is maintained in a part of the COM+ Catalog known as the event store. Tools such as the Component Services manager are used to perform these administrative tasks. The Component Services tool is completely scriptable, allowing much of the administration to be automated. For example, an installation script can perform these tasks during its execution. In addition, the event store can be administered programmatically using the TComAdminCatalog object. The COM+ components can also be installed directly from Delphi, by selecting Run I Install COM+ objects.

As with the tightly coupled event model, an event is simply a method in an interface. Therefore, you must first create an interface for your event methods. You can use Delphi's COM+ Event Object wizard to create a project containing a COM+ event object. Then, using the Component Services administrative tool (or TComAdminCatalog, or the IDE), create a COM+ application that houses an event class component. When you create the event class component in the COM+ application, you will select your event object. The event class is the glue that COM+ uses to bind the publisher to the list of subscribers.

The interesting thing about a COM+ event object is that it contains no implementation of the event interface. A COM+ event object simply defines the interface that publishers and subscribers will use to communicate. When you create a COM+ event object with Delphi, you will use the type library editor to define your interface. The interface is implemented when you create a COM+ application and its the event class component. The event class then, contains a reference, and provides access to the implementation provided by COM+. At runtime, the publisher creates an instance of the event class with the usual COM mechanisms (e.g. CoCreateInstance). The COM+ implementation of your interface is such that all a publisher has to do is call a method on the interface (through the instance of the event class) to generate an event that will notify all subscribers.

Note A publisher need not be a COM component itself. A publisher is simply any application that creates an instance of the event class, and generates events by calling methods on the event interface.

The subscriber component must also be installed in the COM+ Catalog. Again, this can be done either programatically with TComAdminCatalog, the IDE, or with the Component Services administration tool. The subscriber component can be installed in a separate COM+ application, or it can be installed in the same application used to contain the event class component. After installing the component, a subscription must be created for each event interface supported by the component. After creating the subscription, select those event classes (i.e. publishers) you want the component to listen to. A subscriber component can select individual event classes, or all event classes.

Unlike the COM+ event object, a COM+ subscription object does contain its own implementation of an event interface; this is where the actual work is done to respond to the event when it is generated. Delphi's COM+ Event Subscription Object wizard can be used to create a project that contains a subscriber component.

The following figure depicts the interaction between publishers, subscribers, and the COM+ Catalog.

Figure 46.1 The COM+ Events system

Figure 46.1 The COM+ Events system

Clientdataset Delphi

Was this article helpful?

+1 -1

Post a comment