Case Study: Creating a
Plug-in Architecture

Case Study: Creating a Plug-in Architecture

Author: Scott Collins, Synaction Consulting Group

A well established pharmaceutical software company with a product line of statistical clinical applications made the decision to move their flagship product from Visual Basic 6 to C# .net. Rather than performing a direct port of the existing code, the company chose to use this opportunity to re-evaluate the functionality and user interface that existed within their production version. They also wanted to change their position within the market.

Instead of providing a standalone application, the company chose to build the new application upon their own application programming interface (API). This new API would not only be used as the foundation of the new application, but would also be available to third party software companies to license. This would allow third party companies to develop additional functionality that could be sold separately and easily integrated into the application. This would place their product in a unique position compared to their competitors.

Requirements

The new product had to be developed with the following requirements in mind.

The new product would target only Microsoft operating systems.
The system would display large amounts of clinical data to users. Users must have the ability to quickly view and edit any portion of the data.
All clinical data and analysis objects must be able to be persisted in a way that would require no additional products to be installed. If the customer had a database available, then the product should be able to use it to store the information.
The new product must have all functionality that exists within the current version of the product, as well as new functionality to provide users with a way of performing statistical modeling of clinical data.
The current application was developed as a monolithic executable. This made maintaining and adding new functionality difficult. The new application must be developed to allow multiple developers to work independently, without impacting the progress of other developers.
The application must provide a documented public interface to allow third party companies to develop and distribute additional functionality. The interface will be licensed to these third party companies, and there should be no way to use the interface without the appropriate license.

Solution

From the beginning, the team realized that this was a very large undertaking. To make things more interesting, the individuals assigned to come up with the new look and feel of the application wasn't sure of exactly what they wanted. This was a clear case where Iterative development could prove very beneficial. To start, the team gathered very high level requirements so that the scope of the project could be understood. The team then divided the project into small slices that could each be scoped out, designed and developed.

The first few slices involved developing the core of the framework that would eventually become the API. To allow for multiple developers to work independently, and to allow third party add-on functionality, the API was designed to allow for plug-ins. A plug-in is an assembly that registers itself with the main application framework and provides additional functionality through a well defined interface.

Only a few key developers were needed for these slices. Once the core framework was in place, additional developers would be brought in to develop functionality using the plug-in architecture. The main functionality that needed to be developed in the beginning was the framework that loads and runs plug-ins.

architecture diagram

Figure 1. Plug-in architecture

The diagram above shows how the plug-in framework was constructed. There are a number of services that provide different types of functionality to plug-ins. The plug-ins communicate to the services through the framework API. This provides an abstraction between the layers so that the plug-ins are not bound to the specific service implementation. Each of the services can be swapped out and replaced with new services at any time. This allows multiple developers to work concurrently on services and plug-ins, without affecting each other.

This also provides the necessary framework to allow third party companies to develop plug-ins. The API would be made public, and any third party plug-ins would only need to communicate through the API to gain the benefits provided by the services. This solution is also highly maintainable because it is very modular. While writing the code, the developers utilized the Test Driven Development (TDD) methodology. Before writing any actual functionality, the developers wrote all unit tests to ensure that the implementation was coded correctly. This provided the team with a high degree of confidence that the basic framework was a solid foundation in which the rest of the application could be built upon.

To address the remainder of the requirements, the team created several services. The first was an object storage service that would hold all analytic objects and datasets. Another service was the presentation service that defined the overall look and feel of the application, as well as how the user would navigate the process of creating analytic objects.

The replaceable nature of the services allowed the team to develop two separate object storage service implementations. The first managed all objects within either a local or remote directory structure. The second managed all objects using a database. Since both implementations had the same interface in the API, the service implementation could be swapped out without changing any plug-ins. This allowed the product to support both customers with and without a database.

The presentation service abstracted the way that controls are rendered on the screen. This abstraction allowed for the presentation service to be developed using either Windows desktop application controls or as a web application, using ASP.net. The final decision was to make it a desktop application because the user needed to be able to interact quickly with large amounts of data. Although it was developed using Windows controls, the design of the presentation service allowed for the possibility of using a new service implementation that would render ASP.net pages.

Key Technologies Used

Microsoft .Net framework 2.0
Microsoft SqlServer 2000
Several third party control libraries

Conclusion

Several other services were created to provide common functionality required by the plug-ins. Once these services were created, additional developers were brought on board to complete the development of the plug-ins. Due to the design of the plug-in framework, each developer was able to complete the additional functionality of the application and provide a final product within the planned project timeframe.