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

COM+

COM+ Events

Events are widely used throughout development languages and environments. The developer drops a button on a form and adds code to the click method. This code essentially reacts to the click event and performs whatever action the programmer desires.

Similar mechanisms have also been available in COM. ADO is a good example since ADO record sets can query data in an asynchronous manner. Whenever the query is completed, an event is fired, notifying the client that the requested data is now available. Other examples of COM based events are ActiveX controls. Similar to the button example above, ActiveX controls may simply be dropped on a form and code can be added to event code snippets.

In both COM examples, the communication between the COM object/ ActiveX control and the client/ host are accomplished in similar fashion. The COM object (or ActiveX control... you get the idea) and the COM handler object must both be instantiated. In many cases, this happens transparently for the developer. Visual Basic allows the creation of COM objects "with events" and ActiveX controls live inside an ActiveX container object (which is mostly invisible to the developer) that always handles events. The same is true in Visual FoxPro, at least for ActiveX controls. COM objects do not natively support events in Visual FoxPro. However, Microsoft shipped an add-on called the "VFPCOM Utility" that allows the manual creation of a COM event handler object. A handler object has all the code that reacts to events in methods that are named identically to the handled event. The event handler object then needs to be bound (connected) manually to the COM object that fires those events.

This might seem like a lot of extra work, and in fact, represents tasks most development environments take care of for the programmer. But it also demonstrates how COM based events work. Generally, there is always one object that raises the events, and another one that reacts to them. Both objects need to be instantiated and tied together, this step is usually referred to as "event binding". Depending on the language used, event binding may occur at compile time (Visual Basic) or at runtime (Visual FoxPro). Either way, the developer has to take care of the link either in source code or through compiler settings. This is referred to as "tightly coupled events", a technology mostly used for technical issues such as reacting to a mouse click or waiting for data to be retrieved.

However, loosely coupled events are different!

In a loosely coupled event model, we also have an object that raises events (called the "publisher") and one or more objects that react to those events (referred to as the "subscriber"). The major difference is that the two objects are not compiled together, nor are they linked in source code. In fact, the subscriber doesn't even have to be running in memory when the publisher raises an event. All of this is taken care of by the operating system and COM+. To bind a subscriber to an event publisher, the administrator registers the subscriber using the MMC (Microsoft Management Console). Alternatively, this step can be taken care of by the setup program (and I assume this would be the normal case).

These kinds of events make a lot of sense in business situations. For this reason I also like to call these events "business events". Here's an example: Imagine you are the owner of a company that's large enough to employ a full time accountant. However, you would still like to stay in control and be notified whenever the accountant writes a check for more than $5000. Assuming that your accounting package raises COM+ events, you can simply write a mall subscriber component that sends automated email. COM+ even allows the component to be set up in a way so it only receives the event if the check amount is greater than $5000.

How It All Works

Here is an overview of the COM+ Event Service Model:

There basically is an Event Publisher, which can be any COM enabled application. This Publisher invokes a COM object that's registered with COM+ as an Event Class. This Event Class doesn't do a whole lot. In fact it does nothing at all. It only defines the events that can be raised. These events are simply methods that are invoked by the Publisher.

At this point, COM+ takes over. It checks all the subscriptions set up by the administrator (see below). These subscriptions guide COM+ to Event Subscriber objects. Best of all, these objects don't even have to be running in memory! COM+ instantiates them for us as they are needed. This is very important for scalability, as the subscribers are only instantiated when they are used.

Most of this is relatively trivial to set up. In fact, there is very little programming involved. The actual linking part itself is a purely administrative task. This means that a COM+ Events based application can be distributed in a very flexible manner.

So let's have a look at what it takes to program this scenario. As an example, I'm going to develop a scenario that just occurred here 30 minutes ago, when my better half asked my to carry out the garbage. I'm choosing this scenario to demonstrate that COM+ Events are much more business related than any other events models.

Our First Events Class...

We start out with the Event Class. This is the class we will register with COM+ and that will live inside the COM+ Event Service. We will create this class in Visual FoxPro (only Visual FoxPro 7 can create COM+ Event Classes). Simply create a new PRG with the following code:

DEFINE CLASS Garbage AS Session OLEPublic
   PROCEDURE TakeOutGarbage(What As String)
   ENDPROC
ENDDEFINE

OK, this is all it takes to create a COM+ Event Class. There is no code in the methods. This is how we define the "Interface". We leave it to the event subscriber to implement the behavior for this interface (just as it is always up to the men to carry out the garbage...).

We now need to compile this class into a COM Component (create a project named "Wife" and compile it into a multi-threaded COM component) and register it with COM+. The registration is done using the "Component Service" tool that can be found in the "Administrative Tools" folder of your Windows 2000 start menu. This launches the MMC (Microsoft Management Console) with the Component Services Snap In:

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