Event Broker – Introduction

Some of you might already be familiar with the bbv.Common.EventBroker. For those who aren’t I want to give a quick overview of the bbv.Common.EventBroker because knowledge about the event broker is crucial for my future posts about the distributed event broker.

The event broker acts as a mediator between a publisher of notifications (aka publisher) and a consumer of notifications (aka subscriber). The event broker transparently integrates into the usage of classic .NET events by applying a set of attributes either to the publisher’s event or the subscribers event handler. The publisher and the subscriber don’t need to know each other during design time, they are wired up during run time.

In comparison to classical .NET events the bbv.Common.EventBroker offers the following advantages:

• Synchronous and asynchronous notification
• Automatic thread switching: to background or UI thread
• Loose coupling of event topic publishers and subscribers
• Publishers and subscribers are referenced by weak references. Therefore they can be garbage collected
• Multiple publishers and/or subscribers for a single event topic
• Matchers for publications and subscriptions
• Thorough customizable logging
• Extension support

Let’s look into an example…

A publisher of an event could look like:

public class PublisherComponent {
	[EventPublication("topic://SomethingInteresting")]
	public event EventHandler SomethingInteresting;

	protected void OnSomethingInteresting() {
		var handler = this.SomethingInteresting;
		if(handler != null) {
			handler(this, EventArgs.Empty);
		}
	}
}

How the subscriber can subscribe to events:

public class SubscriberComponent {
	[EventSubscription("topic://SomethingInteresting", typeof(Publisher))]
	public void HandleSomethingInteresting(object sender, EventArgs e) {
		// Do something here
	}
}

All we have to do is register both publisher and subscriber on the event broker.

EventBroker eb = new EventBroker();
PublisherComponent p = new PublisherComponent();
eb.Register(p);
SubscriberComponent s = new SubscriberComponent();
eb.Register(s);

When both components are wired up the publisher can fire its events like normal .NET events. The event broker dispatches the event to all interested subscribers registered on the same event broker instance. Imagine how powerful this becomes when you are using a container like ninject, windsor, structuremap… You’ll have the power to auto hook up instances on one or multiple event brokers.

Its true power comes into play when you are leveraging the multithreading and thread synchronization capabilities of the event broker. This can be done by specifying handler types on the subscription and eventually handler restrictions on the publication. A subscriber can specify whether its events are handled synchronously or asynchronously. A publisher can constrain how its event can be handled (synchronously or asynchronously). This is needed for example in events with results in the event arguments that are evaluated by the publisher after firing the event (-> constraint for synchronous handling). A subscriber can request an automatic thread switch if needed onto a background thread or the user interface thread – thus eliminating the need for manual thread switching (no need for Control.Invoke anymore). There exist following options:

• handle on current thread (use Publisher handler)
• handle on background thread from ThreadPool (use Background handler)
• handle synchronously on user interface thread (use UserInterface handler)
• handle asynchronously on user interface thread (use UserInterfaceAsync handler)

More details about the event broker can be found here. For details regarding performance see Urs’ post: http://www.planetgeek.ch/2009/07/12/event-broker-performance/