Plugin architecture (Extensible Application Architecture)


Published on

How to develop extremely extensible software applications. Here we use MEF and MAF to achieve the same.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • In Slide Show mode, click the arrow to enter the PowerPoint Getting Started Center.
  • Plugin architecture (Extensible Application Architecture)

    1. 1. Plugin Architecture Leveraging the benefits of Extensible Application Architecture
    2. 2. Extensible Application Architecture  A very important principle of Application design is the Open-Closed Principle (ref S.O.L.I.D. principles of software design).  The Open-Closed principle states that “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”  It is generally achieved by using abstractions, or by placing behavior(responsibility) in derivative classes.  A truly Extensible Software design should allow 3rd Party/External developers to extend and enhance it further even after they have been compiled and released.  This is possible only if we design our application to be easily Pluggable.
    3. 3. Plugin Architecture Plugin is any piece of software that extends or changes the behavior or interface of an existing, compiled application. For the plugin to be able to extend the any application, the existing application must itself be designed so that its is Pluggable (Implementing a Plugin Architecture). Examples of applications having a plugin architecture are MS Office, Visual Studio, Eclipse IDE (Java) Why/When do we need a Pluggable Application (Benefits)?  To allow applications to be extended after they have been compiled and released.  To allow other applications to be able to connect to and enhance your application in a standard BUT isolated way.  To make Unit testing easier for teams working on different modules/Plugins.  When we are designing a solution which should accommodate disparate requirements implemented by other vendors in the future. Eclipse IDE platform Architecture
    4. 4. Building Extensible design in .NET Microsoft .NET already provides us with a few tools and libraries in order for us to get started with designing Extensible Architectures. The most popular of them all are MEF and MAF. Both are exclusive to each other but can be used in a complimentary manner. A feature-by-feature comparison is as under : Managed Extensibility Framework (MEF) Managed AddIn Framework (MAF) Primarily focused on providing extensibility Provides extensibility along with Isolation All the extensions are loaded in to the same AppDomain as the primary application All AddIns are loaded in separate AppDomains. Dynamic Discovery of Extensions AddIns must be installed before use. No dynamic discovery. Extensions cannot be unloaded at runtime AddIns can be installed/uninstalled without affecting the primary application. The whole application might crash, if and extension has an error/ Since the AddIns run in their own AppDomain, they do not affect the primary application in event of error. Easier to Implement Costly in terms of time, effort and Complexity.
    5. 5. Plugin Architecture Use Case Scenario (MEF+MAF) A custom implementation of a Plugin Architecture using useful features and principles from both MEF and MAF is as under :  The initial Plugin discovery needs to be done using MEF as it supports dynamic discovery of assemblies of a known type in folder.  There is Shared contract which is present in both the Host and the Plugin which assists in the Dynamic Discovery of Plugins.  Info about the loaded plugins such as name, file path, version etc. are stored in a static in-memory collection to be used later.  Plugins are loaded in their separate AppDomains (MAF Principle) as needed (using information from the static in-memory collection), which makes it easy to Load and Unload them.  Since Plugins run in separate AppDomains, they do not affect the Host application in the event of failure/exception.  The communication between AppDomain is a Custom implementation and is achieved using remoting (MarshalByRefObject)  The Plugin Architecture extends to the Plugins as well. Meaning a Plugin itself can also be a Host to other Plugins.
    6. 6. Plugin Architecture Use Case Scenario …continued Illustrated below is a custom implementation of a Plugin architecture.  Each one of the modules (Plugins) below in boxes work independent of each other and communicate via a custom implementation of Remoting. WCF Service (Hosted inside Windows Service) Service A [Plugin] Service Application Service B [Plugin] WPF Application UI Duplex Communication [WCF NamedPipes] UI Application (Shell.exe) [Plugin Host] [Plugin Host] Plugin Y [Plugin] [Plugin Host] Plugin X [Plugin] Service C [Plugin] Future Service [Plugin] Application 1 [Plugin] Application 2 [Plugin] Plugin Z [Plugin] Future App [Plugin]
    7. 7. Glossary Term Description Plugin A piece of software that extends or changes the behavior or interface of an existing, compiled application PluginHost A Pluggable application which can be extended using Plugins. AddIn A piece of software that extends or changes the behavior or interface of an existing, compiled application (same as Plugin) MEF Managed Extensibility Framework ( MAF Managed AddIn Framework ( AppDomain The logical and physical boundary created around every .NET application by the Common Language Runtime (CLR) to isolate applications from each other ( Remoting A means to establish Inter-process communication within the same machine ( WPF Windows Presentation Foundation – Used to create Rich Client Applications ( WCF Windows Communication Foundation – Used to create highly scalable and flexible services ( Named Pipes A mode of communication used by WCF to established Inter-process communication on the same machine.
    8. 8. A solution based on Plugin Framework might be considered as Extreme Extensibility and is not Extensible Applications the way to go for every software design. A Plugin architecture is expensive to implement and must be decided after much thought. Refer the link below to learn more. Find out more about implementing a Plugin Framework with MEF and/or MAF (Click the above link in Slide show mode)