The Rise of OSGi
There is a lot of talk buzzing around about OSGi, the “dynamic module system for Java”. Most famously, an implementation of OSGi forms the basis of the plugin system in recent versions of Eclipse.
So what is OSGi? If you head to the official website for the answer, you could be forgiven for thinking you had stumbled on a game of buzzword bingo. The terms “universal middleware”, “service oriented” and “component based” show up in the first couple of sentences! Putting marketing-speak aside, however, OSGi turns out to be a mature standard for dynamic modules (read: plugins) for Java. Despite the buzzwords, it is also pleasantly simple at its core (plugins are just Jar files with metadata in the manifest). If you’re looking to create a plugin-based application, or to add a plugin system to your existing application, then you should look into OSGi.
In our case, we are adding a plugin system to the next major version of Pulse. We have decided to go with OSGi for a variety of reasons:
- A robust standard for the basic requirements of a plugin system: such as plugin metadata, dependencies, classloading, service management, dynamic loading/unloading and so on. Why reinvent a less complete system?
- A simple core: OSGi plugins (known as bundles) are just plain old Jar files with some metadata. This simplicity will make our life much easier.
- Existing open source implementations: we have chosen the Eclipse foundation’s Equinox implementation, but there are others such as Felix, Knopflerfish and Oscar.
- Eclipse tooling support: as Eclipse uses OSGi under the covers, the Eclipse Plugin Development Environment has tool support for creating and managing OSGi bundles. One of our goals is to make the lives of plugin authors as simple as possible: tool support helps achieve this.
Of course, it is not all good all of the time. There are some challenges we face along the way:
- Lack of documentation: it is seriously difficult to find good documentation about OSGi and the implementations, apart from the standard itself (which happily is reasonably readable). The saving grace is having the Equinox code and a helpful development community.
- Embedding Equinox: the Equinox framework, as part of the Eclipse project, has a certain bias towards being used as part of the larger Eclipse platform (and Rich Client Platform). This is changing over time, but we are finding some interesting challenges embedding Equinox in Pulse.
- Impedence mismatches between Pulse and OSGi: at times the default OSGi behaviour is at odds with how we would like plugins to act in Pulse. For example, OSGi mandates that the state of plugins is persisted by the framework, whereas we want Pulse itself to have control over their state.
As we continue the implementation of a plugin system for Pulse, I’ll post more about the particular things we learn along the way. Hopefully this information will help fill the documentation black hole, particularly in a new area for Equinox: embedding in a standalone application.
This entry was posted on Friday, January 19th, 2007 at 1:20 am and is filed under Eclipse, Java, OSGi, Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
January 19th, 2007 at 10:32 am
Ganeshji Marwaha says:Neat information. I have been hearing about OSGi for sometime in the context of integration with spring. Are you using its spring integration as well?
January 19th, 2007 at 11:00 am
Hi Ganeshji,
Thanks! Pulse does use Spring, but at present we are not using Spring-OSGi. However, we are keeping an eye on Spring-OSGi progress, with the plan of using it in the future.
January 19th, 2007 at 6:12 pm
Peter Kriens says:Could you elaborate about the persistent state? Did you look at start levels? You can easily manage the starting of bundles through start levels.
In 4.1 we also added a transient start method that is not persisted.
Kind regards,
Peter Kriens
January 19th, 2007 at 10:00 pm
Hi Peter,
I have seen start levels, but they do not really address what I need to do. We want Pulse to have more control over plugins being enabled, disabled, installed and uninstalled. For example, we want the user to be able just to remove a jar file and have the plugin uninstalled. In a way, what we are doing is similar to the Eclipse update configurator. In both cases, the persistent state maintained by the framework is undesired. In our case, we start clean and use transient starting (we are using an Equinox 3.3 milestone). In the configurator case, they have to query the framework and redjust all the states to what they actually want.
It seems a shame that the framework goes to all the effort of maintaining the state in for such cases, when it actually harms more than helps. I have to say it also surprised me at first: I didn’t expect the framework to do this sort of stuff under the covers. Adding the option of transient starting is a step in the right direction: that way people can choose whether persistent state makes sense for their application.
January 20th, 2007 at 2:22 am
Alex Blewitt says:OGSi 4.1 provides methods ‘start(int)’ and ‘stop(int)’ that allow you to specify flags, which includes ‘start(TRANSIENT)’ and ‘stop(TRANSIENT)’. These have the effect of stopping the bundle (or starting it) in a non-persistent fashion, such that if a bundle was previously start()ed, then it would stop until the framework restarted; and if that a bundle wasn’t automatically started that start() would bring it up, but only for the lifetime of that instance. It sounds like that may help you.
Alex.
January 22nd, 2007 at 11:23 pm
Matt Ryall says:Thanks for the update, Jason. I’m interested to hear how you get on with including OSGi in your application.
Dynamically loading and unloading plugins is one of the more interesting areas of Java development at the moment. I suspect we’ll be seeing applications getting a lot more dynamic in the next couple of years.
January 24th, 2007 at 12:37 am
Alex,
Thanks for the tip. I had discovered START_TRANSIENT in Equinox 3.3M4, and have been using it. I am still starting clean though, until I figure out if there is any other information being persisted that is not desirable.
January 24th, 2007 at 12:37 am
Hi Matt,
Thanks for stopping by. Hopefully I will find the time to follow up with the details :).
February 1st, 2007 at 2:00 pm
a little madness » EclipseCon 2007 says:[…] As Jason mentioned previously, we are in the process of introducing OSGi into the core of Pulse to handle our plugin support. Since OSGi is also the core of Eclipse, we decided to that a trip to EclipseCon 2007 would be a great way to introduce ourselves into the community and see how people are using OSGi. […]
February 7th, 2007 at 4:19 am
blog.organicelement.com says:OSGi Sighting – Zutubi…
…
May 25th, 2009 at 3:03 pm
Recomended Weekly Link’s (from 19.01.2007) « Dmitry Ulanov’s Opinions says:[…] The Rise of OSGi If you’re looking to create a plugin-based application, or to add a plugin system to your existing application, then you should look into OSGi. […]