What's the best way to get started with OSGI?

Question

What makes a module/service/bit of application functionality a particularly good candidate for an OSGi module?

I'm interested in using OSGi in my applications. We're a Java shop and we use Spring pretty extensively, so I'm leaning toward using Spring Dynamic Modules for OSGi(tm) Service Platforms. I'm looking for a good way to incorporate a little bit of OSGi into an application as a trial. Has anyone here used this or a similar OSGi technology? Are there any pitfalls?

@Nicolas - Thanks, I've seen that one. It's a good tutorial, but I'm looking more for ideas on how to do my first "real" OSGi bundle, as opposed to a Hello World example.

@david - Thanks for the link! Ideally, with a greenfield app, I'd design the whole thing to be dynamic. What I'm looking for right now, though, is to introduce it in a small piece of an existing application. Assuming I can pick any piece of the app, what are some factors to consider that would make that piece better or worse as an OSGi guinea pig?

Answer 1

Here is a good introduction by Neil Bartlett on OSGi : Getting Started with OSGi.

Answer 2

I really like the Apache Felix tutorials. However, I think in general leveraging OSGi in your application isn't one of those "let's use this framework, because it's hype" decision. It's more of a design question, but then everything that OSGi gives you in terms of design, you can have with vanilla Java as well.

As for the runtime, you cannot just add an existing application and make it OSGi enabled. It needs to be design to be dynamic. Spring DM makes it easy to hide that from you, but it's still there and you need to be aware of it.

Answer 3

Well, since you can not have one part OSGi and one part non-OSGi you'll need to make your entire app OSGi. In its simplest form you make a single OSGi bundle out of your entire application. Clearly this is not a best practice but it can be useful to get a feel for deploying a bundle in an OSGi container (Equinox, Felix, Knoplerfish, etc).

To take it to the next level you'll want to start splitting your app into components, components should typically have a set of responsibilities that can be isolated from the rest of your application through a set of interfaces and class dependencies. Identifying these purely by hand can range from rather straightforward for a well designed highly cohesive but loosely coupled application to a nightmare for interlocked source code that you are not familiar with.

Some help can come from tools like JDepend which can show you the coupling of Java packages against other packages/classes in your system. A package with low efferent coupling should be easier to extract into an OSGi bundle than one with high efferent coupling. Even more architectural insight can be had with pro tools like Structure 101.

Purely on a technical level, working daily with an application that consists of 160 OSGi bundles and using Spring DM I can confirm that the transition from "normal" Spring to Spring DM is largely pain free. The extra namespace and the fact that you can (and should) isolate your OSGi specific Spring configuration in separate files makes it even easier to have both with and without OSGi deployment scenarios.

OSGi is a deep and wide component model, documentation I recommend:

• OSGi R4 Specification: Get the PDFs of the Core and Compendium specification, they are canonical, authoritative and very readable. Have a shortcut to them handy at all times, you will consult them.
• Read up on OSGi best practices, there is a large set of things you can do but a somewhat smaller set of things you should do and there are some things you should never do (DynamicImport: * for example).

Some links:

• OSGi best practices and using Apache Felix
• Peter Kriens and BJ Hargrave in a Sun presentation on OSGi best practices
• one key OSGi concept are Services, learn why and how they supplant the Listener pattern with the Whiteboard pattern
• The Spring DM Google Group is very responsive and friendly in my experience

Answer 4

Is your existing application monolithic or tiered in seperate processes/layers?

If tiered, you can convert the middle/app-tier to run in an OSGi container.

In my team's experience, we've found trying to do web-stuff in OSGi painful. Other pain points are Hibernate and Jakarta Commons Logging.

I find the OSGi specs pretty readable and I recommend you print out the flowchart that shows the algorithm for class loading. I'll guarantee you'll have moments of, "why am I getting a NoClassDefFoundError?": the flowchart will tell you why.

Answer 5

There are a couple of thinks to keep in mind if you are starting with OSGi.

As mentioned elsewhere in this thread, knowing about classloading is really important. In my experience everybody sooner or later runs into problems with it.

Another important thing to remember is: never hold references! Have a look at the whiteboard pattern on which the services concept of OSGi is build (see the link in one of the other answers).

In my experience you should not try to convert a monolitic application into an OSGi-based one. This usually leads to a badly and unmanageable mess. Start anew.

Download one of the freely available stand-alone oSGi implementations. I found Knopflerfish rather good and stable (I use it in many projects). It also comes with lots of source code. You can find it here: http://www.knopflerfish.org

Another good tutorial can be found here. https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial

Peter Kriens of the OSGi Alliance gave a nice interview: http://www.infoq.com/interviews/osgi-peter-kriens. His homepage and blog (which is always a good read can be found here: http://www.aqute.biz

Answer 6

Try http://neilbartlett.name/blog/osgibook/. The book has hands on examples with OSGi best practices.

Answer 7

When learning a new technology rich tooling gets you into things without big headaches. At this point the community at ops4j.org provides a rich toolset called "PAX" which includes:

• Pax Runner: Run and switch between Felix, Equinox, Knopflerfish and Concierge easily
• Pax Construct: Construct, Organize & Build OSGi projects with maven easily
• Pax Drone: Test your OSGi bundles with Junit while being framework independent (uses PaxRunner)

Then there are many implementations of OSGi compendium services:

• Pax Logging (logging),
• Pax Web (http service),
• Pax Web Extender (war support),
• Pax Coin (configuration),
• Pax Shell (shell implementation, part of the next osgi release)
• and much more.

.. and there is a helpful, framework independend community, - but thats now advertisement ;-)