Background

With a history stretching back more than a decade, the IGB project has very deep roots, and represents many years of coding effort.  As the project has matured and gained traction in the community, the engineering effort behind the project has become increasingly sophisticated and professionalized.  In recent years, there has been a major effort on the part of the IGB development team to adopt widely recognized software industry best practices in all phases of our software development life cycle.  One particular area we have been focusing on is adopting a modular service based architecture using OSGi.  

Why Focus on a OSGi Modular Service Based Architecture?

Reduced Complexity

By refactoring our monolithic application into isolated "modules" of independent functionality we are able to greatly reduce its complexity.  This reduction in complexity comes in many forms, but one of the more obvious reductions comes from simply reducing the number of considerations which must be dealt with at the same time. 

Reduced Number of bugs

The reduction in the number of bugs is achieved simply because a modular system is safer in than a monolithic application due to the reduced complexity.  There is a reduced cognitive load involved in making changes, adding new features, or fixing existing bugs.  

Plugin API for External contributors

The efforts we have made and continue to make to modularize the IGB code base have the incredibly beneficial side effect of leading to a software system which is already pluggable/extendible in a huge variety of ways.  The reason why a plugin API is the natural organic output of this refactoring effort is obvious. Each time we find existing functionality in code which is being isolated into a module we must evolve our APIs to allow for extensibility to accomodate. If for example, we find some code which is adding a menu option into the main IGB toolbar, then we must then create mechanisms in the plugin API to allow for the addition of menus to this toolbar (e.g. the addtion of an interface to implement).  These mechanisms are then available to all future module developers to leverage which writing their own extensions to IGB.  

Enforced Interface/Service Based programming

In Object Oriented Programming the benefits of proper interface based programming have been known for a long time (see http://en.wikipedia.org/wiki/Interface-based_programming), and with OSGi we are able to take this well known best practice and enforce it. 

IGB Module Overview

Module Types

The IGB project currently consist of 54 modules, and these modules can be grouped into the following groups.

1. Library Modules - modules which are only contributing "utility" classes for consumption by other modules (e.g. guava, apache commons)
2. API Modules - modules which only contain service interfaces, abstract classes, data model, or similar content.  (e.g. the igb-services-api module)
3. Implementation Modules - Modules which implement instances of the interfaces/abstract classes contained in API modules.  There implementations typically will take the form of a registered OSGi service, requiring none of the internal content of bundle to be exposed.
4. Blended Modules - Small modules which may both define API content and publish implementation content within the same module.  We do not consider this improper in most cases as long as the package exports are ensuring a proper separation of concerns and not exposing internals.  As a rule, 
   only expose API, utility classes, and data model. 

The modularization effort of our project in ongoing, so there are some known violations within our own codebase of the best practices described above, but these will be resolved as our work continues.

Important IGB Modules for External Developers

• igb-services-api - An API module containing most of what would be needed by any external contributor.  This is the primary API jar of the project.
• igb-swing-ext - A Library module which may be needed by contributors interested in leveraging some of the swing components used elsewhere throughout the codebase.
• common - A Library module which has many useful utilities used frequently in our internal modules. 
• genometry - A module containing much of the data model used in the project. Admittedly, this module needs more work and will in the future be reworked into additional modules, but there is a high likelihood developers contributing significant functionality to the project will need to depend on this module.