As long as the publisher, the event class, and the subscribers are all installed on the same machine, you can have pretty much any topology of interaction (see Figure 9-12). On the same machine, publishers can publish to any event class, event classes can deliver events to any subscriber, and subscribers can subscribe to as many event classes as they like.
Unfortunately, the COM+ event service has a serious limitation—the event class and all its subscribers have to be on the same machine. This means that a deployment, such as the one shown in Figure 9-13, is not possible.
The rest of this section presents you with a few workaround solutions for this problem that allow you to distribute your events across the network. All the solutions adhere to the limitation that the event class and the subscribers have to reside on the same machine, and they solve the problem by designing around it. Like most things in life, each solution has pros and cons. It will be ultimately up to you, the system designer, to select the most appropriate solution for your domain problem at hand.
This solution is the simplest to implement. You install all event classes on one machine, along with all subscribers. You install the event classes in a COM+ server application and generate a proxy installation (see Chapter 1) for the event classes’ application. (Remember, the event class application has to be a server application for you to export it as a proxy application.) You then deploy the event class proxy application on all the machines that host publishers, making sure the proxy applications point to the event classes/subscribers machine (see Figure 9-14). .
When a publisher on a remote Machine A wants to fire an event of type E1, it creates a proxy for that event class and calls the event method on it. The event call will be marshaled to the place where the event class resides—on the subscribers machine—and get published to all the subscribers that subscribed to it. It is also very easy for subscribers to subscribe to more than one event class, since all the event classes are installed locally on the subscribers machine
This solution has the following disadvantages:
By locating the event classes away from the publishers, you introduce extra expensive round trips across the network.
The single machine hosting all the event classes and the subscribers becomes a hot spot for performance. The machine CPU and operating system have to handle all the traffic. There is no load balancing in your product, and load balancing is a major reason for distributing your components in the first place.
The subscribers machine solution is a single point of failure in your system.
The subscribers are not necessarily ideally deployed. If the subscribers do not have to reside where the event classes are, you may have put them somewhere else—maybe on the same machine where the database is if they have to access it frequently. Performance may suffer.
This solution allows you to distribute your subscribers anywhere, according to whatever design preference you have. This distribution makes it possible for you to publish from one machine to subscribers that reside on multiple other machines (see Figure 9-15). However, this particular solution is more complex to manage and deploy than the previous solution.
The idea behind this solution is to create a COM+ events hub on one designated machine. The hub machine is responsible for distributing the events to where the subscribers really reside.
This solution uses two kinds of event classes. The first is an event class that resides only on the hub machine, called Eh. You install proxies to Eh on all the publishers’ machines. Publishers will only publish using Eh.
The second kind of event class is a machine-specific event class. Every machine that hosts subscribers has its own dedicated event class type, installed only on that machine. In Figure 9-15, these types are Ea, Eb, and Ec, corresponding to the three machines in the figure. You need to install a proxy to every machine-specific event classes on the hub machine. All event classes in this solution support the exact same set of sink interfaces.
When a publisher on Machine A wants to publish an event to subscribers on Machines A, B, and C, the publisher on Machine A creates an instance of the Eh event class (which only actually creates a proxy) and fires to it. The Eh proxy forwards the call to where Eh really executes—on the hub machine. On the hub machine there is a hub subscriber (Sh) that subscribes to the Eh event. The way Sh handles the event is to create all the machine-specific event classes (Ea, Eb, and Ec) and fire that particular event to them. Because there are only proxy installations of the machine-specific event classes on the hub machine, the event is distributed to multiple machines, where local subscribers—the real subscribers—handle the event.
The main advantage of using this solution is that it gives you complete freedom in locating your subscribers. However, the flexibility comes with a hefty price:
When you publish, you encounter many expensive round trips across the network. Even if all the subscribers are on the publisher machine, the publisher still has to go through the hub machine.
You have to duplicate this solution for every kind of event class you have, and you therefore end up with separate sets of machine-specific and hub event classes.
The added complexity of this solution means that you probably have a deployment, administration, and maintenance nightmare on your hands.
The hub machine is potentially a single point of failure in your system.
This last solution for distributing events to subscribers on multiple remote machines takes advantage of a feature provided for you by COM+. However, it is a partial solution because it only works with persistent subscribers. If your application uses transient subscribers (as it most likely will), you have to use one of the two solutions discussed previously. The idea here is similar to the hub machine solution, and to distinguish between them, I call this one the routing solution.
COM+ provides a field called Server name on the Options tab for every persistent subscription (see Figure 9-16).
Figure 9-16. Instructing COM+ to create the subscriber object on the machine specified in the Server name field
Whenever an event is published to a persistent subscriber, before CoCreating the subscriber object, COM+ first checks the value of the Server name property. If it is not an empty string, COM+ CoCreates the subscriber on the specified machine, fires the event to the sink interface, and releases the subscriber.
Routing events to multiple machines takes advantage of this feature. Instead of using machine-specific event classes like in Solution 2, the routing solution uses machine-specific persistent subscriptions.
For example, suppose you have a publisher on Machine A and a subscribing component called MySubscriber that you want to deploy on Machines B and C. The publisher publishes using an event class called E. On Machines B and C you add subscriptions to the event class, to the locally installed copies of MySubscriber. You then install the MySubscriber component on another designated routing machine, together with the event class E, and install on Machine A only the proxy to E (see Figure 9-17).
To the installation of MySubscriber on the router machine (called SR in Figure 9-17) add machine-specific subscriptions: for every deployment of MySubscriber on another machine, add a subscription and redirect the invocation to that machine, using the Server name field. See Figure 9-18.
Figure 9-18. The router machine has a machine-specific subscription used to route the event to corresponding machines
Now, when the publisher on Machine A CoCreates a proxy to the event class and fires an event at it, the call goes to the router machine. COM+ inspects the subscriptions on the router machine for the event class, detects the Server name in the subscriptions, creates the subscribers on the remote machines, and publishes to them.
I already pointed out the main drawback of this solution (persistent subscribers only), but it has a few others:
Setting up and configuring the system is nontrivial effort. You have to either write some installation scripts to help you automate it or manually configure it at every customer deployment. Every customer site has its own machine names; you will not be able to specify the machine names in your application MSI file, exported for release.
You have to go through the router machine, so you end up paying for an extra network hop.
The router machine can be a performance bottleneck.
The router machine is potentially a single point of failure.