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:

Cleanup

Assemble a small team of modularity experts, and ensure management backing

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.

>> several commenters have demonstrated that OSGi is a great choice for both application servers and middleware.

If you want to get a taste of OSGi, I would recommend anyone to build a small Eclipse RCP application with 3-5 plugins, assembled in a couple features using some external libraries. I am not talking about downloading a sample and compiling it. I am talking about building your own RCP project.

OSGi solved a very complex modularity/versioning problem for its plugins. But overall the technology is undertooled and underdesigned. There is no real explicit assembly mechanism like in SCA, (which I think is a better choice for building modular server-side middleware), OSGi is just a bag of bundles. IMHO it is a better Java classloading mechanism, it offers no real support for higher level concepts such as Component or Services.

The core of OSGi is the "export package" statement. Yes, you just export a "package" and you let other bundles simply have visibility into it. You are pretty much on your own to add semantics to the link between the "packages". If you want to get a sense of what "wiring" means in OSGi, you can take a look at this post: www.dynamicjava.org/articles/osgi-matters/tackl....

In the end, OSGi is a vendor centric technology at best, and I am not surprised MuleSource chose something else, I doubt that many IT organization have been successful using OGSi "over-the-cover". Last but not least, OSGi does not have any operational component.

If you want to get a taste of OSGi, I would recommend anyone to build a small Eclipse RCP application with 3-5 plugins, assembled in a couple features using some external libraries. I am not talking about downloading a sample and compiling it. I am talking about building your own RCP project.

So far so good. Where things start to get ugly is when you want to automate your build, run unit tests on the build server, share project configuration among developers on different platforms etc. You'd think this kind of stuff ought to work "out of the box", but you'd be wrong.

[...] it offers no real support for higher level concepts such as Component or Services.

What information is the metadata lacking? Note that you can attach arbitrary properties to any package or service you export (and filter on those properties when importing). First time I see someone complaining about OSGi not being complicated enough :-)

What is referred to as "clean-up" above is compile-time modularity. The entire point of which should be to encourage cohesion and minimize coupling in your codebase.

OSGi targets runtime modularity. Any project with a large, older codebase should first target compile time modularity. Can you even compile the components separately? Or is your code too tightly coupled?

The article proposes developers look at the tooling and metadata targeting OSGi as soon as they have achieved compile-time modularity. The "clean up" itself should involve tooling selection. I would suggest you first look at build tools that encourage modularity. The big one in Java is Maven (now version 3) but Gradle, and Buildr might also work for you. By making dependency management easy, these tools encourage developers to build smaller interrelated projects. Of course, this is possible with Ant+Ivy, but you have to carefully monitor your scripts to make sure no one breaks the patterns you are trying to encourage. In any cases you have to monitor each projects dependencies.

Your primary goal should be to build small independent libraries, that are only bound to each other through clean APIs. These APIs should be libraries that are also independently compiled, released, and versioned. If you do this, you will know where the boundaries exist in your application and will be able to easily enforce them. Developers will be encourage to use the API by not having the implementation available at compile time. Nothing like broken builds, or IDEs not displaying implementation classes in code completion dialogs, to change developer behavior.

After you've done this, then ask if OSGi is right for your organization. You'll probably find that 99% of what you wanted to use OSGi for has already been achieved.

The primary remaining benefits of OSGi include:1. Bundle hot swapping2. Separate classpaths for bundles3. The ability to mark classes in a bundle exposed or not.

Most organizations:1. will have server farms and not need OSGi bundle hot swapping, or even allow it in production environments.2. Dependency management will begin to eliminate the need for classloader separation, though some edge case will most likely continue to exist.3. By compiling against APIs and testing against implementations of those APIs (or mocks) good separation of concerns will be enforced at compile time.

I've introduced Maven builds in to several companies now. Sometimes effecting small groups of developers (10 or so) sometimes whole companies (200+ developers). One had plans to use OSGi, which was scrapped once the costs of maintaining bundle information on all their projects and those project's dependencies was weighed against what was gained by using OSGi once modularity was already achieved and enforced in the build process.

1) The lack of a clean central repository for OSGi bundles that have package level includes and excludes of commonly used open source java libraries is incredibly painful. Most bundle repos are low quality package scoped bundles, or very small. Bundle level includes strike me a poor implementation. Not something I would choose to introduce in to an application, unless absolutely necessary.

2) Build tools do not currently support OSGi well enough. You will be repeating yourself while maintaining the manifest file. Which destroys much of the value of declarative, DRY build tools like Maven, Gradle, and Buildr.

Right now for almost any web based application the move from a modularized application to a modularized application + OSGi doesn't seem worth it.

If anyone has a different experience please let me know, it's been over 6 months since I last spiked this. An example of a build that generates OSGi modules with package level imports and exports for all components while adhering to DRY principals, and a sizable repo of such modules, would change my mind.

Until then, I'll keep my codebases clean with compile time modularity and see how the on going OSGi/Jigsaw battle plays out.

One thing i have yet to figure out how to solve is how to develop and maintain multiple plugins. i.e. I need to use binary plugins until i need to make a change. Then i need to "checkout" the source of the plugin, work with that and then use the binary of the plugin after checking in the source and creating a new version of the plugin. Any hints or pointers? (Mainly i am building Eclipse RCP and Eclipse RAP apps)