[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]

This launches the Subscription Wizard that guides you through a couple of simple steps. First of all, we select the class/ interface we want to subscribe to. We simply click the checkbox for "…all interfaces…" and proceed. When we move to the next step, the system searches the registry and it might appear as if it was hung for a moment, but it really isn't. In fact, when you move the mouse cursor over the (disabled) listbox, it will actually change its appearance to the hourglass. Once this process is done, the wizard displays the class that defines the selected interface (Wife.Garbage in our example). We select that class and proceed.

Now, all that's left is to specify a name for the subscription (I called it "marriage") and to enable the component right away. Voila! We have newlyweds, where all the details of the contract are handled by COM+. In fact, the whole relationship is rather relaxed and the wife so far doesn't even know what happened to her (I'm convinced that whoever at Microsoft was in charge of this technology must have been male…).

Publishing Events

We are all set to handle and subscribe to events now. All that's missing at this point is an event publisher that actually makes the wife fire an event (imagine my cat just tripped over the garbage can…). In the COM+ world, this can be any COM enabled client. In this example, I'm using Visual FoxPro's command window, which allows to us to directly enter the following commands without creating a program of any kind. Here's the first command that instantiates the wife object:

Wife = CreateObject("Wife.Garbage")

This created the object and we can visually verify that through the Component Service Manager where the little ball representing the wife object starts spinning. Note that the event subscriber is not instantiated at this point since it has not received any event notifications yet.

We can now go ahead and publish events. This means, we essentially fire methods on that object, like so:

Wife.TakeOutGarbage("Kitchen")

Immediately, the message box implemented in the husband object will fire and display "Kitchen" (which is the parameter we passed in). Also, when you look in the Component Service Manager, you will see that both balls are instantiated and spinning now.

Click the OK button in the message box to complete that task, and you will see that the reference to the husband object is released immediately even though the wife object is still in memory.

At this point, the wife assumes her request is taken care of. Little does she know he only replied with a mumbled "yeah-yeah" but didn't actually get away from the TV.

That is the very nature of COM+ events. The events fired by the events class are published to the system where any number of subscribers could react to that event. However, that number of subscribers could very well be zero (all wives know what I'm talking about). In fact, the wife doesn't even get a chance to verify whether there are subscribers, and if they have taken care of the desired task, other than checking the trash can again.

This means that the system is great for one of the following two scenarios:

1. We know we have a reliable subscriber because we created and configured it ourselves and there is no need to directly check up on it. An example would be a reclamation sent by a customer that is put into a database. The system will then publish an event that states that a complaint was filed and we hope that some subscriber takes care of it. We also keep checking our basket (database) of complaints and re-issue the event until it is taken care of.
2. We already handled all tasks internally, but publish the event anyway so other components can make use of certain business events and perform additional tasks. In this scenario, we would take care of the complaint ourselves, but we publish the event, so any other component (such as an email component) gets a chance to react to it and perform additional action.

Event Filters

At this point, our husband component is subscribing to all events the wife may fire, and this may very much be the desired behavior, at least from the wife's point of view. I think I'm pretty good with these kinds of things, and the garbage has been taken out from the kitchen every time I was asked to do so (thankfully, we have a maid…). However, there is one thing I'm not particularly excited about: cleaning the litter box. I refuse to subscribe to that event. The COM+ equivalent to this is "Event Filters".

Right click on the subscription you created and select "Properties". In the "Options" page, you will find a setting for a "Filter Criteria":

Here you can specify filters based on the passed parameters. In our example, the filter criteria looks like so:

NOT What = "Litter Box"

You can now publish the event again as we did before, and the husband object will react every time, unless the passed parameter is "Litter Box".

This is a very important feature for scalability and flexibility (and for a happy marriage…). Typical uses would be stock updates where a subscriber only reacts to events that have to do with stock that is in a certain portfolio. Or maybe our complaints subscriber only reacts to complaints concerning orders of significance based on the order amount. So every order that is returned that had an order amount of more than $100,000 is directly reported to the CEO by email, but we don't bother her with smaller issues. Obviously, this can be set up in a very flexible manner without changing source code or adding configuration options to your system.

Events can also be filtered based on the COM+ component that fired the event. This is useful in scenarios where one subscriber subscribes to events fired by a number of different components (that all use the same interface).

Queued Components

Asynchronous messaging is crucial for scalable as well as highly reliable applications, providing 100% uptime even in offline/ disconnected scenarios and at high peak times. Microsoft provides a standard asynchronous messaging mechanism through MSMQ (Microsoft Message Queue). Queued Components use this mechanism to provide a very specific (yet very common) implementation of asynchronous messages: Asynchronous component invocation and execution.

Some Scenarios

The better understand the value of Queued Components, consider the following scenarios:

Online Store

Online stores (at least the successful ones) often encounter very high peak times where handling the amount of traffic becomes the main priority. Every time a customer places an order, a number of different processes take place and a number of different tasks have to be taken care of. Here's a short (and incomplete) list to give you a better idea:

1. Order has to be stored
2. Credit card has to be processed
3. Inventory has to be updated
4. Order fulfillment has to take place
5. Statistics have to be updated
6. Confirmation mail has to be sent
7. Managers may have to be informed
8. Staff has to be notified by email
9. …

Many of these tasks are very time consuming. Sending confirmation and staff email may be a problem during peak times. Updating statistics is most likely a very time consuming process. So is credit card processing.

However, not all of these tasks have to be performed at the time the order is placed. Most likely, the credit card will be charged right away, but there is no need to update the sales statistics at real time while the customer is waiting for a response. Neither is it necessary to send confirmation emails or staff emails during the process sending confirmation emails can take place a couple of seconds or potentially even hours later. The order fulfillment may be an entirely different system altogether.

So if all those tasks can be stored away for the time being, the actual hit that performs the time-critical task is much shorter. Shorter hits not only take up less processing time and resources, but they also are much easier to scale.

MSMQ provides a fault-proof way of "storing away those tasks". This is referred to as "queuing". Basically, the Queue is used as the temporary holding area for those tasks. So in our scenario, the order entry system would simply store a message indicating that there are sales statistics to be updated, emails to be sent, or simply that an order has been received.

So far, a familiar scenario for people using MSMQ. However, there is a lot of overhead and programming that goes along with setting up this kind of a scenario. With Queued Components, these scenarios become much easier to implement. Basically, during the hit all the required components are called at real-time (at least from the clients point of view). In reality, some of those components might be set up to be queued, meaning that rather than instantiating the actual component, COM+ creates a recorder that records all the method calls and stores them in the Queue. The client does not really know about any of that. Later, COM+ instantiates the real component and "plays" the recorded information. The used component doesn't really know that it is called by the COM+ player. It just receives a number of messages and performs its tasks as if it was invoked synchronous. So all the complexity of queuing and asynchronous messaging is taken care of by COM+es Queued Components feature.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]