adam bien's blog

How To Kill An OSGi Project - With 10 Questions 📎

OSGi focusses on modularity and it is right now (future may change it) the only viable way to split your application into modules with well-defined dependencies. It solves, however, "only" the technical problem - which is actually relatively easy. Before you going to introduce OSGi into your project, answer the following questions:
  1. What is your versioning scheme for modules(bundles)? Do you care about minor versions, major versions etc?
  2. Whats your scm strategy - do you plan to open and maintain a branch for every version of a module? How many branches do you plan to maintain? (with svn? :-))
  3. How many versioned modules will be active at the same time in production?
  4. How the system is going to be tested? Each module and all the combination of modules. Every version will increase the complexity significantly.
  5. What is your release-management strategy? Do you really plan to provide customer-specific module combinations? What is your bug-fixing / patch strategy (trunk, branch)?
  6. Do you really want to replace modules in running system? If it is a serverside system - what happens with in-flight transactions?
  7. If it is an Eclipse-RCP application - are you even allowed to expose the plugins to the end-user? (in the majority of my projects, we had to disable the update manager in production :-))
  8. What is your software distribution system - many companies have already a software-distribution system in place. Often not only the application, but also the JVM are packaged into one binary file and entirely installed. Incremental updates are often impossible.
  9. What is exactly the contract between the modules? Only a Java-Interface? If so - what to do with direct relations between JPA-entities. If you disallow direct JPA-relations - you will probably see a huge "domain" package with all domain objects inside it. You will need to provide "friend" relations between modules as well.
  10. Is maven the canonical representation of modules, OSGi, or both? A single representation would be the best. Will maven module versions be reflected in the OSGi bundle versions?
The major OSGi-challenge is not the technology, rather than the governance of your modules and bundles. The problem is very similar to SOA.

For most enterprise applications you will get only one variant of your business logic, or even UI - so you will end up with modules, which will probably never be replaced. Because of additional complexity - you will probably test and deliver the whole system at once.

If you are building an IDE, platform or a server - governance, modularization and versioning are a major part of your problem domain / functional requirements. You will have to solve that anyway. It is far more likely, that someone will have to install a new driver to an application server, or even maintain different versions of the driver at the same time. IDEs without plugins are also extremely rare.

Replacing an algorithm in a business application is far more uncommon - often even not allowed. Its just crazy to introduce a modularization solution and then not use it.

[See also "Real World Java EE Patterns, Rethinking Best Practices" book, Page 253, (Premature Encapsulation Is the Root of All Evil) for more in-depth discussion]