Business Benefits of OSGi

Recently, Paremus blogged about the business benefits of OSGi, in which they argue the case for modularity as the way forward for managing and maintaining large codebases. The report also suggests how a migration towards OGSi might be achieved, initially by generating OSGi metadata through automated builds, and then by migrating applications individually over to run on an OSGi framework.

Many consider the cost of migration onto OSGi expensive, but frequently this is conflated with the cost of modularity itself. Whether OSGi, Jigsaw or a different modularity scheme is used, modularising a large, complex and heavily intertwined library is an expense that has no immediate benefits to the maintainers. However, if left to rot, the system will become more complex, intertwined and larger over time and the maintenance cost will increase. Much as a car should be regularly serviced to keep it in good condition, if left unserviced for many years the cost of an engine overhaul may be more than the cumulative cost of the services and even shorten its lifespan.

Paremus suggest the following migration plan:

1. Cleanup
   1. Assemble a small team of modularity experts, and ensure management backing
   2. Analyse dependencies between existing projects and remove superflous or unsatisfied dependencies
2. Tooling and metadata
   1. Review and use tooling and repositories that supports OSGi metadata
   2. Generate OSGi metadata as part of the build process for all projects (even if not switching to OSGi)
3. Runtime
   1. Select candidates for migration based upon agility and reusability concerns
   2. Create working runtime bundles using existing libraries as the level of granularity
   3. Concurrently test in both OGSi and non-OSGi runtimes
4. Iterate
   1. Once migrated to OSGi, there may be further candidates for modularity in existing libraries
   2. Report on shared modules
   3. Migrate subsequent applications individually

Success stories

Since the blog post regarding the failure of MuleSoft to migrate to OSGi, several commenters have demonstrated that OSGi is a great choice for both application servers and middleware.

• All major JavaEE application servers run on top of OSGi (GlassFish, WebSphere, JBoss)
• SAP are adopting Virgo as their OSGi runtime
• WSO2 Carbon runs successfully on OSGi
• Apache Camel is an ESB (like Mule), but which can run inside and outside of an OSGi container
• JBoss has its own OSGi runtime in development

Like many other frameworks, the use of OSGi does not guarantee success, and will often require some adoption or code changes in order to migrate. Indeed, OSGi isn't right for everyone – but just because it isn't right for one project has no bearing on whether it is right for another project. One probably wouldn't use OSGi for a single-use application to parse a CSV and load it into a database – but then, one probably wouldn't use Spring or any other framework for that matter. (Some would say that would be better in Python or Perl, rather than Java, in fact.)

OSGi remains a tool in the modularity space that can be used to aid in modularity and to enforce module boundaries between them. As projects become larger, the value gained by using a strong modularity system outweighs the cost of implementing modularity.