SE Radio 104: Plugin Architectures

6 comments

• Can you guys comment on the difference between plug-in system with software product line system? Thanks.

• Product Lines are all about systematically managing variability in software systems. There are various ways to do that. One way is to have a plugin architecture and have different plugins for different products in the product line.

• Hi Fanchuan

  I consider plug-in architectures as a technical means to support certain variability/orchestration in the solution when doing SPLE. So they are related, but they are not at the same conceptual level.

  Best regards,
  Michael

• Thanks for the interesting episode. It seems plugins encapsulate up quite a important part of software architecture, meaning modularity, extensibility, separation of concerns. Perhaps relating plugin (architectures) to the architectural aspects covered in previous episodes would have been great.

  I’ve still got some questions. At the end you elaborated on the need for plugins. I think until you really need the features mentioned above you should stay with a simple architecture and refrain from the “over”engineering of an plugin architecture. So the eclipse way of creating extension points and plugins as needed is probably a good way to go.

  On the other hand separating your application into distinct modules is heavily supported by the use of plugins. There you are forced to really separate the concerns as there are no shortcuts to take when using functionality offered by other parts of the application.

  I find it interesting that the eclipse team which is a worldwide distributed team is using a plugin architecture. Is this another manifestation of Conway’s law?

  There are aspects of plugin architecture and development that I would like to have covered in a subsequent episode.

  My main concern is on testing the stuff. On the one hand there is the basic plugin architecture that has to work under all circumstances. On the other hand if you have an application that is extended by several plugins (of which you perhaps don’t know) – How do you assure that it still works? There must be a lot of integration testing on the side of both the application authors and on the side of the plugin developers to make sure that this all works out.

  Another thing is how to support developers of plugins? You need extensive documentation, examples and perhaps even IDE support for creating the plugins. A test harness that simulates different aspects of the application (using stubs or mocking) would be necessary as well.

  Finding bugs / debugging in such a plugin ecosphere is also not that trivial as you have to be able to reproduce the configuration/context in which the bug occurs and interaction between different plugins hinders the search for errors as well.

  Configuration and dependency management are two other important aspects of extensible applications. Like a SOA architecture in a smaller scope you need to invest much effort (configuring eclipse 🙂 ) to get the stuff working together in the way you want. There is also the problem of incompatible plugin versions and conflicting dependencies.

  So lots of open questions in this area 🙂

  Michael

  Michael Hunger
  Independent Software Developer
  Don’t stop where you are: Creating Passionate Developers

• Hi, Michael.

  your comment on refraining from “over” engineering is certainly right. You should definitely not create plugins just because of doing plugins. Nevertheless you mention the positive effects of plugins with regards to separation of concerns, modularity, etc. And this is exactly what makes me loving plugin architectures: I ALWAYS want to have a good and clear design in my system (following modularity, separation of concerns and many other design principles), starting right away from the beginning. Therefore I tend to always base my system development on a kind of plugin architecture. But again, this does not mean to create hundreds of plugins just because of doing plugins is fun. The question of what to put into which plugins should be related to those design principles. I think this is somehow the way the Eclipse team is developing their system.

  Interesting that you ask for Conways Law in the relationship to the Eclipse architecture. I think they succeeded in creating a nice match of their distributed development teams and their system architecture.

  The testing topic you are talking about is absolutely interesting. And I would agree that testing the whole system becomes come challenging. I have two different things in mind when thinking about this testing issue:
  If you define your system as a set of plugins but your team is the only one adding or removing plugins, your testing becomes more or less the same as having a system where everything is build into it. You test the system with all plugins being deployed. This is different if you have different teams or even different communities contributing plugins. For this case the Eclipse team has the policy that a provider of an extension point must be implemented in such a robust way that extensions to this point cannot damage the extension point providers functionality. This idea seems to be pretty interesting from the testing point of view. You could test your extension point provider plugin by inserting many different kinds of mock extensions to test whether your extension point provider works correctly or not, even if the mock extensions simulate some ugly stuff.

  There are definitely many open and interesting topics and questions in this area… 🙂

  Cheers,
  -Martin

• Hi Michael,

  thanks for your questions. The answers actually depend on the system at hand, so here is a non-Eclipse view.

  > I think until you really need the features mentioned above you should stay with a simple architecture and refrain from the “over”engineering of an plugin architecture.

  Plug-ins can be used nicely when you know the system would be large, and you look for a way to leave things out that you could deliver later. If you are then interested in upgrading your installations instead of a full re-install, plug-ins can be for you despite the “over”engineering.

  On testing…
  In the industrial plug-in applications I have seen, there were typically a few plug-ins. They were all of the same type (i.e. satisfying the same hot spots) and independent of each other. Their development was contracted to external partners, small teams or freelancers.

  Noteworthy: the applications were ready by then, but needed more plug-ins to become more useful for customers. So during the plug-in development, a test harness was available so that the development team could simulate actual behaviour. Finally one week of integration testing was scheduled (and mostly sufficient) to integrate the plug-in into the production system. The plug-in development was considered done when the integration tests passed.

  The application owner were aware that without plug-ins, the application would be virtually useless. Thus they paid for the plug-in development and provided adequate documentation and support. All plug-in developers were independent of each other; for cross-plug-in integration, solely the application was responsible.

  The configurations were way simpler than in Eclipse settings, with just a handful plug-ins installed, and all of them mutually independent – per architectural paradigm. In such a setting, the plug-in concept actually reduces the system’s complexity instead of increasing in. To me this is a litmus test whether to choose a plug-in architecture. If you want to ship an industrial application in different variants, it must be configurable very easily and without much opportunity for introducing errors…

  Klaus