Message passing in a plug-in framework

Question

First off, there's a bit of background to this issue available on my blog:

• http://www.codebork.com/coding/2008/06/25/message-passing-a-plug-framework.html
• http://www.codebork.com/coding/2008/07/31/message-passing-2.html

I'm aware that the descriptions aren't hugely clear, so I'll try to summarise what I'm attempting as best I can here. The application is a personal finance program. Further background on the framework itself is available at the end of this post.

There are a number of different types of plug-in that the framework can handle (e.g., accounts, export, reporting, etc.). However, I'm focussing on one particular class of plug-in, so-called data plug-ins, as it is this class that is causing me problems. I have one class of data plug-in for accounts, one for transactions, etc.

I'm midway through a vast re-factoring that has left me with the following architecture for data plug-ins:

• The data plug-in object (implementing intialisation, installation and plug-in metadata) [implements IDataPlugin<FactoryType>]
• The data object (such as an account) [implements, e.g., IAccount]
• A factory to create instances of the data object [implements, e.g., IAccountFactory]

Previously the data object and the plug-in object were combined into one, but this meant that a new transaction plug-in had to be instantiated for each transaction recorded in the account which caused a number of problems. Unfortunately, that re-factoring has broken my message passing. The data object implements INotifyPropertyChanged, and so I've hit a new problem, and one that I'm not sure how to work around: the plug-in object is registering events with the message broker, but it's the data objects that actually fire the events. This means that the subscribing plug-in currently has to subscribe to each created account, transaction, etc.! This is clearly not scalable.

As far as I can tell at the moment I have two possible solutions:

1. Make the data plug-in object a go-between for the data-objects and message broker, possibly batching change notifications. I don't like this because it adds another layer of complexity to the messaging system that I feel I should be able to do without.
2. Junk the current event-based implementation and use something else that's more easily manageable (in-memory WCF?!).

So I guess I'm really asking:

1. How would you solve this problem?
2. What potential solutions do you think I've overlooked?
3. Is my approach even vaguely on-track/sensible?! :-)

As you will be able to tell from the dates of the blog posts, some variant of this problem has been taxing me for quite a long time now! As such, any and all responses will be greatly appreciated.

The background to the framework itself is as follows:

My plug-in framework consists of three main components: a plug-in broker, a preferences manager and a message broker. The plug-in broker does the bread-and-butter plug-in stuff: discovering and creating plug-ins. The preferences manager manages user preferences for the framework and individual plug-ins, such as which plug-ins are enabled, where data should be saved, etc. Communication is via publish/subscribe, with the message broker sitting in the middle, gathering all published message types and managing subscriptions. The publish/subscribe is currently implemented via the .NET INotifyPropertyChanged interface, which provides one event called PropertyChanged; the message broker builds a list of all plug-ins implementing INotifyPropertyChanged and subscribes other plug-ins this event. The purpose of the message passing is to allow the account and transaction plug-ins to notify the storage plug-ins that data has changed so that it may be saved.

Answer 1

This is my understanding of your question: You have a plugin object that may have to listen for events on x data objects - you don't want to subscribe to the event on each data object though. I'm assuming that several plugins may want to listen to events on the same data object.

You could create a session type object. Each plugin listens for events on the session object. The data object no longer raises the event - it calls the session object to raise the event (one of the parameters would have to be the data object raising the event).

That means that your plugins only have to subscribe to one event, but they get the event from all data objects.

On the other hand, if only one plugin will ever listen to a data object at a time, why not just have the data object call the plugin directly?