What Are Subscriptions?

Distributed applications can't rely on a specific connection existing at any given time-the client and server might not even have a connection. Therefore, the request/reply event system is unlikely to work with a distributed application. The lack of a connection between the client and server forces us to create some new method of handling events. COM+ provides this new event-handling methodology, which is known as the publish/subscribe even system.

In the old setup, there was a client and a server with a direct connection. The client registered an event handler directly with the server. The publish/subscribe event system, on the other hand, uses an intermediary to handle the client/server communication. In short, the publish/subscribe event model has three main elements:

1. The server publishes data through an event class that it registers with Component Services. Once the server publishes data, it's no longer concerned about where the data goes. In other words, the server has no knowledge of which clients receive the data that it publishes.

2. The client subscribes to an event that the server publishes. However, unlike COM client, which registers with the server, the COM+ client registers with the COM+ Catalog. In reality, the client has no idea which server provides the data. All it knows is there's an event it wants to subscribe to. Therefore, we have a server publishing the data and a client subscribing to the data, but we don't have a connection between the two. That's where the event object comes into play.

3. The server creates the event object before firing an event. When the server fires the event, the event object receives it. At this point, the server can terminate if it wants to-it has fired the event, and the event object will handle the details of notifying subscribers. The event object looks through the list of subscribers in the COM+ catalog, and then notifies each subscriber. In short, the event object is the COM+ part of the picture-the intermediary between the server and the client.

At this point, you might be wondering what this three-element method buys you in the way of productivity or reliability. Creating the server is certainly easier. The server doesn't need to provide a request interface or handle client function pointers. All it needs to do is fire an event, nothing more. The subscriber, similarly, needs to know nothing about the server. All it needs to do is implement an interface. This interface has the same name as the server's interface. In short, you can create two components, change components , or even create entirely new functionality using this method without having to change both the client and server. All you need to worry about is implementing an interface with the correct name .

The event object is simple too. All it really contains is stub code (empty functions). The COM+ Event System Service handles the actual event object details. It merely uses the event object you create as a template of the interfaces and methods it needs to handle.

Another advantage of using the publish/subscribe methodology is that you can combine it with Microsoft Message Queuing Services (MSMQ). A COM server (publisher) could queue up changes that would wait until the host computer has time to service them. Likewise, the event object can queue the fired events until the client can pick them up. Consequently, neither the client nor the server has to exist during event handling.

You must consider several subscription issues when working with COM+. The first is the type of subscription you want to create: transient or permanent. The type is determined by the type of registration you want to perform: manual or dynamic. We've already discussed methods for manual component registration in the other COM+ chapters of the book. The following sections describe the two subscription types and the dynamic method of registering a component.

Understanding Transient Subscriptions

Transient applications allow you to make a quick subscription to an event object without spending a lot of time traversing the COM+ catalog. In addition, transient subscriptions won't survive a reboot, which means that applications that fail in the middle of a session won't leave permanent bits of themselves behind. Generally, you'll use transient subscriptions for users on the road or for situations where a connection is easily broken. Because transient subscriptions won't survive a reboot, you can clear them from your system with relative ease.

Understanding Permanent Subscriptions

Permanent subscriptions are located in another part of the COM+ catalog and require a lot more work because you have to first locate the right application. The advantage of a permanent subscription is that it survives reboots and tends to be more efficient for use by long- term applications such as server-based components.

Understanding the Need for Dynamic Registration

Sometimes you don't want to clutter the global assembly cache with components that will see intermittent or temporary use. That's where dynamic registration comes into play. Theoretically, you can place an assembly containing a serviced component in the application folder for a COM+ application. When a client requests services of the component, the component is loaded dynamically. The COM+ applications for a given machine appear in the Program Files\ComPlus Applications folder. You can find out more about this procedure at ms-help://MS.MSDNQTR.2003FEB.1033/cpguide/html/cpcondynamicallyregisteringassembly.htm .