The Developer's Resource & Community Site

COM	XML	ASP	Java & Misc.	NEW: VS.NET
International	This Week	Forums	Author Central	Find a Job

Introduction to COM+ events

Author: Paddy Srinivas
Date Submitted: March 1 2001

Introduction:

One of the classic programming problems in distributed computing is how to advertise and deliver information to one or more interested parties without prior knowledge of their identity. The programs involved in context are Publishers - components that provide notifications to others and Subscribers - components that receive notifications from publishers.

Prior to Windows 2000, COM Connection points were one of the ways to address this problem. COM+ events addresses many shortcomings of Connection points and have the following advantages over it. Some of the advantages of the COM+ Event System are:

1. Com+ events don't need the lifetimes of the Publisher and the Subscriber to overlap.
2. Publisher and subscriber do not need to have an intimate knowledge of each other.
3. Com+ events allow filtering and interception.

Figure 1: A typical COM+ events life cycle

The COM+ Event system has three players. The Publisher that publishes the events, The Subscriber that is the indented recipient of the event and the Event Object that implements the Firing interfaces.

Sequence of operation is:

1. An event Class is registered.
2. Subscriber registers for an Event.
3. Publisher creates an Event Object at run time.
4. Publisher fires the Event by calling the method in the Event Object
5. Event Object reads the Subscription List from the Event Store
6. Delivers the event to the subscriber by calling the appropriate Method

Filtering

The above mentioned scenario describes the simplest case of event generation and delivery. Though this approach is very easy to develop and deploy but it does not give the kind of flexibility that is usually required in real enterprise applications. The concept of getting a better handle on the delivery of the events to the subscribers is referred to as Filtering.

There can be two types of filtering namely Parameter filtering and Publisher filtering.

Publisher Filtering

Publisher filtering brings further refinement to the Events model by controlling the event notification. This helps to control the order of delivery of the events and also lets the filter implement business logic to control the firing of the event.

When the publisher creates an event object and fires an event, the events system in turn creates the publisher filter object and passes on the responsibility of calling the subscribers to the publisher object, which in turn implements its own business logic and decides the subscribers and the order of delivery of the events.

The Publisher filter object controls the order in which the events are delivered to the multiple subscribers. Publisher filtering allows the publisher to determine which subscribers will receive a particular event.

The two main objectives of publisher filtering are:

1. Implement business logic in the filter object to determine which subscribers will receive the event that is triggered by the publisher.
2. Control the sequence of event delivery

A Publisher filter object has to implement one of the two interfaces IPublisherFilter or IMultiInterfacePublisherFilter. The later is used in the case of the event class having multiple firing interfaces.

The filter objects implementing IMultiInterfacePublisherFilter have two methods, Initialize and Preparetofire.

IMultiInterfacePublisherFilter::Initialize is called when the publisher creates an event object. This method hands a IMultiInterfaceEventControl pointer to the filter object. This interface is used by the filter object to get a list of subscriptions for a specific event (method) of a firing interface.

IMultiInterfacePublisherFilter::PreparetoFire is called when the publisher invokes a method of the firing interface. The three parameters of this method are the InterfaceId of the firing interface, the method name and an IFiringControl interface.

STDMETHODIMP CCFilter::PrepareToFire(REFIID _riid, BSTR _methodName,
		IFiringControl *_pFiringControl)

In the implementation of this method, the filter object uses the cached IMultiInterfaceEventControl interface pointer in the Initialize method to call GetSubscriptions to get a list of subscribers who are interested in this event. This call places the list of subscribers in an IEventObjectCollection.

CComPtr<IEventObjectCollection> pEventObjects;
int iErr;

// Here we get the list of subscriptions for this event
 HRESULT hr = m_pEventControl->GetSubscriptions(m_iid, m_strMethod, NULL, &iErr, &pEventObjects); 

Using this collection we can get an enumerator object (IEnumEventObject) by calling the get_NewEnum method of the IeventObjectCollection.

CComPtr<IEnumEventObject> pEnumEventObjects;

hr = pEventObjects->get_NewEnum(&pEnumEventObjects) ; 

Once we get the enumerator object, the subscriber objects can be extracted one by one by calling the "Next" method . This method is called in a loop to extract all the subscribers for a specific method of the firing interface. Once the filter has the subscribers, it can implement the business logic to determine which subscribers it wants to implement.

ULONG pcRetElem;
CComPtr<IUnknown> pUnk;
CComBSTR bstrSubscriberCLSID;
while(pEnumEventObjects->Next(1, &pUnk, &pcRetElem) == S_OK)
{
CComQIPtr<IEventSubscription> pSubscription(pUnk);
pUnk.Release();
		if(!pSubscription)
			return E_NOINTERFACE;
	// Implement the business logic here 
		hr = m_pFiringControl->FireSubscription(pSubscription);
}

Parameter Filtering

This type of filtering provides an administrative way of filtering events based on the values of the parameters of the fired event.

Figure 2: Specifying filtering criteria for a subscription

In this example Temperature and Pressure are the parameters of the Event being fired. The filter criteria string recognizes relational operators, for checking equality (=, ==, !, !=, ~, ~=, <>), nested parentheses, and logical keywords AND, OR, or NOT.

Parameter filtering occurs after any publisher filtering and when the standard event object is fired for a given subscription. If publisher filtering is also used for the same event, parameter filtering occurs only when the publisher filter invokes IFiringControl::FireSubscription. Hence, publisher filtering and parameter filtering can compose together, but publisher filtering takes precedence.

---

Contribute to IDR:

To contribute an article to IDR, a click here.

To contact us at IDevResource.com, use our feedback form, or email us. To comment on the site contact our webmaster.

All content © Copyright 2000 IDevResource.com, Disclaimer notice