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
- Analyse dependencies between existing projects and remove superflous or unsatisfied dependencies
- Tooling and metadata
- Review and use tooling and repositories that supports OSGi metadata
- Generate OSGi metadata as part of the build process for all projects (even if not switching to OSGi)
- Runtime
- Select candidates for migration based upon agility and reusability concerns
- Create working runtime bundles using existing libraries as the level of granularity
- Concurrently test in both OGSi and non-OSGi runtimes
- Iterate
- Once migrated to OSGi, there may be further candidates for modularity in existing libraries
- Report on shared modules
- 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.
Community comments
A word of caution
by Jean-Jacques Dubray,
Re: A word of caution
by Eric Jain,
Re: A word of caution
by Jean-Jacques Dubray,
OSGi is about runtime modularity
by Rex Hoffman,
Actions speaker louder than words
by richard nicholson,
Mutliple Plugin development
by Mac Noodle,
A word of caution
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
>> 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.
OSGi metadata is poor and offers no real visibility into the "assembled" product. Here is a quick introduction blog.springsource.com/2008/02/18/creating-osgi-... on the metadata.
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.
Re: A word of caution
by Eric Jain,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
OSGi does have a notion of services, see e.g. www.knopflerfish.org/osgi_service_tutorial.html.
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 :-)
Re: A word of caution
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
>> OSGi does have a notion of services, see e.g. www.knopflerfish.org/osgi_service_tutorial.html.
sorry, I have to laugh.
OSGi is about runtime modularity
by Rex Hoffman,
Your message is awaiting moderation. Thank you for participating in the discussion.
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 swapping
2. Separate classpaths for bundles
3. 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.
I've kept my eye on OSGi, occasionally spiking against Spring DM, or plain Equinox. My findings are this:
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.
Actions speaker louder than words
by richard nicholson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Alex - thanks for your well crafted summary of my post - much appreciated.
With respect to the comments on OSGi tooling from some of your readers.
Paremus and Neil Bartlett are combining efforts to pull elements of the SIGIL IDE tooling (see felix.apache.org/site/sigil-key-features.html), into a new version of BNDtools project (njbartlett.name/bndtools.html). The derivative will offer a powerful and elegant OSGi development tooling experience for all those enlightened OSGi developers out there.
This together will other industry efforts from the PAX / OPS4J folks and Eclipse Tooling team will rapidly kill off any OSGi tooling criticism in 2011.
All constructive contributions welcome.
I'll address some of the other comments at a later date.
Best Wishes
Richard
Mutliple Plugin development
by Mac Noodle,
Your message is awaiting moderation. Thank you for participating in the discussion.
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)