IGB Developer's Guide
Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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 blended 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. 
  • genoviz-sdk - A Library module containing many custom components built on by IGB for visualization.  Developers working on custom visualizations may have a need to depend on this module.

Module Classifications

  • Core Modules - Modules considered to be critical to the core IGB application
  • Plugins - Modules providing content which expands the functionality of the core IGB application, but which are not required for its basic operation.  
    • Default Plugins - Although many plugins are not required, we choose to enable many plugins by default (e.g. weblinks, bookmarks).  The line between default plugins and core modules can be fuzzy since many of the functions provided by the default plugins are very important to our application, and the classification system may evolve to eliminate this category
    • Optional Plugins - Plugins which are providing useful functionality, but for one reason or another has been deemed to be an opt in feature for users (e.g. 23andMe-snp-converter, igb-command-socket)
    • Development Plugins - An opt in set of potentially incomplete work or functionality not well tested and therefore not released.

 

 

 

  • No labels