The core of the design is formed by a class called Subscription.

The name is quite self describing, but let me say some words about its intended purpose in my publish & subscribe implementation. The subscription is used as an endpoint for sending messages to a subscriber, hiding away the thread context (SynchronizationContext) of the related subscriber instance and the weak reference handling to the related subscriber instance from the caller. It’s a kind of mediator instance so to say. Besides that it provides some information about which message type the subscription is for.Subscriptions are created by an implementation of the ISubscriptionAssembler interface. As the name implies the main responsibility of this interface is to create subscriptions either in an explicit (create a single subscription for a given ISubscriber<TMessage> instance) or implicit (infer all subscriptions of a given instance / type) manner . . .

The current implementation (SubscriptionAssembler) uses a small wrapper around SynchronizationContext called SyncFactory to capture the thread context while building the subscription. All this factory does is that it registers a new SynchronizationContext via SyncronizationContext.Current when no context exists. This is especially useful when doing unit testing (which by default has no SynchronizationContext set).

Besides that the SubscriptionAssembler provides functionality to infer all subscriptions of a particular type and / or instance via reflection. This is done on top of the classes SubscriptionInspector and MessageInterestCache. The SubscriptionInspector realizes the relflection part, while the MessageInterestCache serves as a small cache for optimizing the performance of the assembler (message interests are only reflected once). Also included is a bit of functionality which can be used to pre-infer the message interests of a particular type, which might get handy when integrating with an InversionOfControl-container (most IoC-container split registration and type construction).

Once subscriptions have been created, they are managed by an implementation of the ISubscriptionManager interface. This means:

1. Tracking all subscriptions for a particular message type (with operations for adding / releasing and retrieving subscriptions for a particular message type).
2. Detecting and removing dead references (garbage collected instances).

The actual IMessageBus implementation called MessageBus is implemented only as a small wrapper around the ISubscriptionAssembler (for creating subscriptions) and the ISubscriptionManager (for adding and removing subscriptions explicitly). Here you can impression what it actually does:

public class MessageBus : IMessageBus
{
        private readonly ISubscriptionManager _SubscriptionManager;
        private readonly ISubscriptionAssembler _SubscriptionAssembler;

        public MessageBus(
            ISubscriptionManager subscriptionManager,
            ISubscriptionAssembler subscriptionAssembler)
        {
            Ensure.ArgumentIsNotNull(subscriptionManager, "subscriptionManager");
            Ensure.ArgumentIsNotNull(subscriptionAssembler, "subscriptionAssembler");

            _SubscriptionManager = subscriptionManager;
            _SubscriptionAssembler = subscriptionAssembler;
        }

        public void AddSubscriber(ISubscriber subscriber) where TMessage : class
        {
            Ensure.ArgumentIsNotNull(subscriber, "subscriber");

            Subscription subscription = _SubscriptionAssembler.CreateSingle(subscriber);
            _SubscriptionManager.Add(subscription);
        }

        public void ReleaseSubscriber(ISubscriber subscriber) where TMessage : class
        {
            Ensure.ArgumentIsNotNull(subscriber, "subscriber");

            _SubscriptionManager.ReleaseSubscription(subscriber);
        }

        public void SendMessage(TMessage message) where TMessage : class
        {
            Ensure.ArgumentIsNotNull(message, "message");

            var subscriptions = _SubscriptionManager.GetSubscriptions(message.GetType());

            foreach (Subscription subscription in subscriptions)
            {
                subscription.SendMessage(message);
            }
        }
}

The interface to an InversionOfControl-container is the IocBridge. This class is just a small mediator that can be used in combination with the extension method the container provides. It provides simple access points which call an ISubscriptionAssembler implementation, when an instance has been configured, try to infer all subscriptions when a new instance has been created and that release all subscriptions related to a particular instance when the instance has been removed from the container.

Regarding the design of the publish & subscribe system that’s all there is to tell . Here is a little overview over all classes.

In the last post I mentioned that my favourite IoC-container is Castle Windsor. In order to use the library there still is a little piece missing. I’ve integrated it with the WindsorContainer by implementing an IFacility.

public class PubSubFacility : AbstractFacility
{
        private IIocBridge _IocBridge;

        protected override void Init()
        {
            _IocBridge = Kernel.Resolve<IIocBridge>();
            Kernel.ComponentModelCreated += OnComponentModelCreated;
            Kernel.ComponentCreated += OnComponentCreated;
            Kernel.ComponentDestroyed += OnComponentDestroyed;
        }

        private void OnComponentDestroyed(ComponentModel model, object instance)
        {
            _IocBridge.UninstallInstance(instance);
        }

        private void OnComponentCreated(ComponentModel model, object instance)
        {
            _IocBridge.TryInstallInstance(instance);
        }

        private void OnComponentModelCreated(ComponentModel model)
        {
            _IocBridge.TryTypeInstallation(model.Implementation);
        }
}

Together with some xml the whole stuff can easily be wired together.

<castle>
<components>
<facilities>
<facility
id="PubSubFacility"
type="BjRo.CastleContrib.PubSub.PubSubFacility,
BjRo.CastleContrib.PubSub" />
</facilities>

<component id="PubSubFacade"
type="BjRo.PubSub.IocBridge, BjRo.PubSub"
service="BjRo.PubSub.IIocBridge, BjRo.PubSub"
lifestyle="Singleton" />

<component id="MessageBus"
type="BjRo.PubSub.MessageBus, BjRo.PubSub"
service="BjRo.PubSub.IMessageBus, BjRo.PubSub"
lifestyle="Singleton" />

<component id="SubscriptionAssembler"
type="BjRo.PubSub.SubscriptionAssembler, BjRo.PubSub"
service="BjRo.PubSub.ISubscriptionAssembler, BjRo.PubSub"
lifestyle="Singleton" />

<component id="SubscriptionManager"
type="BjRo.PubSub.SubscriptionManager, BjRo.PubSub"
service="BjRo.PubSub.ISubscriptionManager, BjRo.PubSub"
lifestyle="Singleton" />
</components>
</castle>

That’s it with my take on (local) publish & subscribe. It may not be perfect but it suits my needs at the moment. I’m planning to integrate the standard .NET APM in the IMessageBus interface in order allow asynchronous message sending and the common rendezvous techniques. I’m looking forward to any feedback for my solution and would like to share the code under some OS license, if someone is interested in. . .

public interface ISubscriber<TMessage>
{
     void Handle(TMessage message);
}

The generic parameter TMessage specifies the type of message the subscriber is interested in.  The message should simply be implemented by a POCO. Examples could be:

• ISubscriber<ActivePatientChanged>
• ISubscriber<ApplicationTitleChanged>
• ISubscriber<CsvExportFinished>

A consumer class wants to publish messages or to register itsself for a particular message needs to have a reference to an IMessageBus implementation. This interface serves as a consumer side facade to the pubsub system.

public interface IMessageBus
{
      void AddSubscriber(ISubscriber subscriber);
      void ReleaseSubscriber(ISubscriber subscriber);
      void SendMessage<TMessage>(TMessage message);
}

From a consumer perspective that’s all your need to known when dealing with publish & subscribe. Together with type inference it’s event nicer to use .

public class DemoMessage
{
}

public class MyListener : ISubscriber<DemoMessage>
{
     public void Subscribe(IMessageBus bus)
     {
          bus.AddSubscriber(this);
     }

     public void Handle(DemoMessage message)
     {
     }
}

public class MyPublisher
{
     private IMessageBus _Bus;

     public MyPublisher(IMessageBus bus)
     {
          _Bus = bus;
     }

     public void Demo()
     {
         _Bus.SendMessage(new DemoMessage());
     }
}

Some other characteristics also worth mentioning:

• The current implementation captures the thread context when a subscriber is registered. All callbacks will be handled on the same thread on which they were registered.
• Only a weak reference is held to the subscriber. This guarantees that a subscriber can be garbage collected although not properly unregistered from the publish & subscribe system. The implementation detects dead references and removes them automatically.

With that beeing said I would like too conclude the series about publish & subscribe with a post about the actual implementation which will follow up . . .

What I liked about publish & subscribe in CAB:

• The automatic thread marshalling. (Basically you’re able to specify whether the subscription-callback will be handled on the UI-thread or the same thread as the publisher)
• The wiring was done during the build process in the ObjectBuilder. Publishers and Subscribers are completely decoupled. Wow, this was pretty amazing for me when I discovered that late 2005 .

What I didn’t like about it:

• It is very tightly coupled to a CAB internal data structure called WorkItem. (Not reusable outside the scope of CAB)
• It uses standard .NET events / delegates. (The publisher needed to define an event and the subscriber needed to have a public method with a matching “object-sender-eventargs-e” – signature.)
• It uses attributes and especially a string based topic identifier to correlate publishers for a topic and corresponding subscribers. (Maybe I’m narrow-minded on this, but I think the simplest way to specify a subscription is the best, which imho is expressing a subscription by implementing an interface.)

Many frameworks or libraries I looked into over time mostly followed a comparable approach using either events or some other delegate-based solution (the EventBroker in CAB, the EventBrokerFacility in Castle Windsor, the EventAggregator in PRISM, ….) (Please correct me if I overlooked or misunderstood something ). The only framework I came across with something similar to what I had in mind is Caliburn.

Unfortunately Caliburn is a WPF/ .NET 3.0 based framework, but most of the products of my current employer are limited to .NET 2.0 due to a minimum system requirement of Windows 2k. Because of that I decided to implement something similar for our purposes which can be easily integrated into the InversionOfControl – container of our choice (which is Castle Windsor at the moment, by the way ).

I’ll be describing the implementation and publish the source code for anyone who is interested in one or more follow-up posts . . . .