Tag Archives: architecture

Very simple plugin mechanism in C#

NET%20LogoOnce again I had to face the famous content aggregator problem. I already have done that on several project so I decided to write an article on that for the ones who wonders how to accomplish things like that.

Background

So, the situation is : I have a system, who consume several services, aggregate the results and provide the output to the user. I also want to be able to develop each providers class as separated assemblies (plugins) so the providers can develop their own plugins and distribute them to the software users without having to recompile the application, just by dragging the assembly within a folder. Here’s a diagram that resume the situation.

Plugin1

Technical Analysis

Regarding the requirements, some answers can seem obvious. First, we need to provide an interface to define what’s a plugin. Then, we need something to control the plugin creation and access. This component will also be responsible in this case for the plugin call. Each providers will have his own implementation of the IPlugin interface. In this case, the manager called PluginProvider, will be a singleton instance and instantiate the plugins on creation. Here’s the basic UML diagram of the system with some example providers.

Plugin2

Then, we have a dependency tree like this one

Plugin3

The assemblies that contains plugins will be placed in a folder where the application will look at startup. They just need to know the interface to implement and the data types exchanged if required. The UI layer refer the core, that contain the PluginManager and the shared assembly. No references to the plugins are created.

Implementation

The implementation is pretty simple. Here’s our plugin interface :

public interface IPlugin
{
    string Name { get; }
    void Action();
}

Then we can implement a basic plugin like this :

public sealed class ExternalPlugin : IPlugin
{
    public string Name
    {
        get { return "Exemple Plugin"; }
    }

    public void Action()
    {
        DoSomething();
    }
}

And finally, the most important thing, the PluginManager.

public sealed class PluginProvider
{
    private static PluginProvider instance;
    /// Warning ! Not a thread safe implementation, change it if needed
    public static PluginProvider Instance { get { return instance ?? (instance = new PluginProvider()); } }

    private List pluginInstances;

    private PluginProvider()
    {

    }

    public void Initialize()
    {
        pluginInstances = pluginInstances ??
               (from file in Directory.GetFiles(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"Plugin\"), "*.dll")
                from type in Assembly.LoadFrom(file).GetTypes()
                where type.GetInterfaces().Contains(typeof(IPlugin))
                select (IPlugin)Activator.CreateInstance(type)).ToList();
    }

    public void Action()
    {
        if(pluginInstances != null)
            pluginInstances.ForEach(plugin => plugin.Action());
    }
}

So, first we have a basic not thread safe singleton implementation. When we call the Initialize() method, the Linq query will list all the dll in the Plugin application folder, load each assemblies, find the types that implement IPlugin and then create an instance of them. All the instances are then stored in the pluginInstances private list. When we call PluginProvider.Instance.Action(), we iterate over each instance and call the Action() method. If the method return something, we can easily adapt the code to aggregate the call returns and return it to the PluginProvider caller. And that’s pretty much it !

Conclusion

This architecture can then be improved with for example repositories for query caching, using code contract to improve strength, using a thread safe singleton implementation, using a facade to directly call Providers.Action() or make this generic to be able to work with any interface which inherit from IPlugin… With all these improvements you’ll start to have a kind of little plugin framework in our personal toolbox. Modularity is usually a key factor in software development and that kind of pattern are really usefull for a lot of scenario.

If you have any questions, feel free to ask in the comments below 🙂

See you next time and keep it bug free !

MSMQ : Architecture et principes

Présentation de MSMQ

MSMQ, acronyme de Microsoft Message Queuing est une implémentation Microsoft de Message Queue. Une Message Queue est un ensemble de techniques permettant l’échange asynchrone de messages. Par exemple, une boite mail peut être considérée comme un MQS (j’utiliserai par la suite cette abréviation pour parler de manière générique des message queuing system), càd un endroit où l’on peut déposer de l’information dans le but d’être traité plus tard. Ainsi, dans sa version basique, l’émetteur ne se soucie pas des actions entreprises par le destinataire, tablant sur le fait que le message étant présent dans le queue, il sera traité par qui de droit quand il en sera capable. C’est donc un composant utilisé pour communiquer de l’information entre différent processus ou différent thread d’un même processus permettant.

C’est queues prennent souvent la forme de « stack » et donc hérite des propriétés de ces dernières. Bien que majoritairement de type FIFO, les 3 opérations standards des stack (push/pop/peek) ainsi que les opérations utilitaires (status/count/clear/dup/swap) sont implémentées par les fournisseurs de Message Queue. Si ces notions vous sont étrangères et souhaitez utiliser activement des systèmes de queue, je vous conseils de faire un petit tour par wikipedia 😉

Dans la pratique, on ne développe que rarement ses propres systèmes de queues et l’on préfère déployer des solutions existantes fonctionnant « off-the-shelf » comme IBM Webshpere MQ/Message Broker, MSMQ, JMS, RabbitMQ,… Ensuite on définit des queues nommées dans lesquels les applications viendront déposer leurs messages dans le but d’être traitées par d’autres systèmes ensuite. On délègue la responsabilité de la gestion des messages (envoi, routing, ACK, …) et de l’infrastructure au système de message queuing  ce qui permet découpler de souvent l’application cliente et serveur en utilisant le MQS comme « interlocuteur privilégié ».

Pour résumer, je vais refaire mon analogie avec la boite mail du point de vue de l’emetteur et du destinataire, remplacez boite mail par queue, mail par messages et le tour est joué 😉

Une boite mail est un espace de stockage de message accessible par des applications et gérée par une application serveur. Quand je veux envoyer un mail à quelqu’un, j’indique l’adresse de sa boite mail, écrit mon mail et envoi ensuite le mail au serveur d’envoi qui le transfert vers le serveur du destinataire qui, basé sur l’adresse de la boite mail principalement, peut placer le message dans un espace accessible par le propriétaire de l’adresse. Lorsque j’envoie un mail, je ne me soucie ni de l’emplacement de mon destinataire, ni du client de messagerie qu’il utilise ni de sa disponibilité. Je n’ai besoin que d’un protocole commun d’échange (SMTP pour le mail) compris par les deux parties. Je pars du principe que le mail étant envoyé, mon destinataire le lira quand il ira relever son courrier.

Le destinataire lui, lorsqu’il consulte sa boite mail, vas souvent du plus ancien non-lu au plus récent, (accès séquentiel). Mais rien ne m’empêche d’accéder directement (accès aléatoire) au message qui m’intéresse en me basant sur par exemple les métas données du mail (émetteur, objet du message, flag d’importance, …) Un fois le message consulté, je le supprime de ma boite mail (plus actuellement avec les boites mail illimité) ou le place dans un dossier de tri pour le consulter plus tards.

MSMQ, c’est une sorte de service mail pour les applications. Lancé depuis NT4 et Windows 95, MSMQ  tire parti de l’intégration au système microsoft et en fait un système d’échange de message très correct pour beaucoups de besoins. MSMQ à une déclinaison cloud pour Azure, appelé Azure Storage queue et AppFabric Service Bus. Des systèmes de messaging complexe sont aussi disponibles par exemple pour les ESB, mais cela dépasse de loin le scope de cet article.

Propriétés d’MSMQ

Le diagramme ci-dessus résumé l’échange de messages MSMQ. On y distingue deux types d’applications. Les applications d’envois et celles de réceptions. Voici les caractéristiques et options principales de chacune :

Sending Receiving
(non)/Transactionnel Lecture local ou remote
Express/Recoverability (non)/Transactionnel
Envoi direct ou en store and forward (une copie sur   chaque intermédiaire) Lecture synchrone ou asynchrone
Authentification Lecture en peek ou retreive
Encryption Online ou Offline
Online ou Offline  

 

Je vais détailler certains points qui peuvent sembler peu explicite.

Express/Recoverability permet de stocker une copie du message et d’attendre un ACK de la part du destinataire. SI le ACK ne parvient pas, le message sera ré-envoyé jusqu’au moment où le destinataire
confirmera la bonne réception du message. C’est un peu comparable à UDP/TCP.

Direct/Store-and-forward. En store-and-forward une copie du message est gardée sur chaque intermédiaire. Cela permet par exemple de ne pas interrompre l’envoi du message dans le cas où un des intermédiaires serait inaccessible.

Peek/Retrieve. En Peek, le message est conservé dans la queue alors qu’en retreive l’accès à un message le supprime de la queue.

Conclusion

Nous avons maintenant une idée globale de ce que propose MSMQ. Dans le prochain article je vous ferai une petite démo de comment utiliser MSMQ depuis du C# sur un scénario simple pour une application de chat. A bientôt 🙂