Message passing in a plug-in framework problem

Question

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

• http://www.alastairsmith.me.uk/coding/2008/06/25/message-passing-a-plug-framework.html
• http://www.alastairsmith.me.uk/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 fires 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?! :-)

Many thanks in advance for the time and effort you put into your responses. 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

Wow! Big question! :)

Correct me if I'm wrong. Your basic solution now is kind of an Observer pattern, where the data object (Account, etc) notifies about changes in their states. You think that the problem is that the subscribing plugin has to register in every object to be able to handle notifications.

That's not a problem per se, you can put the event control in the Domain Model, but I suggest you create a Service Layer and do this event notifications in this layer. That way just one object would be responsible for publishing notifications.

Martin Fowler have a series of Event Patterns in his blog. Check it out! Very good reading.

Answer 2

It's early yet, but have you considered trying to use MEF instead of rolling your own?

Answer 3

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?

Answer 4

Thank you all for the responses.

Dave: this app is a project that I'm using as a learning tool for patterns, architecture, etc. I should have made this clear in the question; my apologies. As such, whilst I would normally look at MEF in much more detail, I will this time file it away as useful information for the future :-)

Dan, Marcio: you have the situation correct. It is most definitely "a kind of Observer pattern" (focus on the "a kind of" :-) From your description of the session object, Dan, this sounds like a superset of my message broker, and as such I feel this presents the most elegant solution for the situation. I'll investigate this next time I have a moment!

Marcio, your solution also sounds very plausible, but it doesn't present to me an immediately obvious implementation as Dan's does. Having followed the links you provided, I think I'd have to read Fowler's book before I was able to make any progress with this method! I tried searching Wikipedia for more information on the two mentioned patterns with all but no success.

Additionally (and I know I might be wrong here), I feel that enterprise patterns are overkill for this app. Although it's quite a heavily-architected framework, it's not as colossal as most enterprise apps are. I'm aware, though, that enterprise-based ideas can be applied elsewhere, so I'm happy to have my view changed :-)

Many thanks again; I'll vote on your answers once I've attained another four reputation points!