Has anyone found OSGi to be useful in corporate ap

Question

Has anyone deployed a corporate application in OSGi and found it useful?

I can see the benefits, forced modularity, good dependency definitions etc. But these seem to be mainly build related improvements.

Has anyone found it useful to dynamically replace an existing module? We tend to split our application by process and to be honest, it's not that difficult to startup a new instance of the app with updated libraries. Would OSGi be useful for this?

How reliable is the replacing of a module? It strikes me that if you have a very busy process with lots going on, replacing a running module is fraught with danger.

Answer 1

We're using it in a big telecom. We have it in production for 2 years and we're continuing adding bundles now we have about 110 bundles.

Operation guys are delighted for the fine control this give to them: they can start stop single functionalities and monitoring them. Theoretically we could also hotdeploy a new version in production, but in the reality we use that feature only when doing test and preprod.

Our broad brush architecture is based on this one: http://servicemix.apache.org/home.html

Our main problem is always try to use standard java framework within osgi. The second problem is the bundle import/export management itself. We're using maven plugin.

All in all we're happy with this choice but you need to consider 2 things: 1. are you willing to fight with any java framework you want to add? 2. are you disciplined enough to not mess up your dependency?

Answer 2

I work in a telecom environment. Something like OSGi will be very useful for us. We deploy applications to clients who cannot go offline without taking a hit on revenue. They process thousands of calls per second. Right now, they have to do the updates in their maintenance window to take in new fixes or updates.

If we can deliver fixes and enhancements as a hot deploy, it will be of a great benefit. But of course there is a risk factor and extra testing efforts with simulated traffic test before we can do it.

OSGi is not just for dynamic updates, it is good for things like versioning to assure that the right version is being picked in a complex environment.

We are starting to look into OSGi, I will post updates if I find anything more interesting.

---

Answer 3

I have just blogged about why we didn't go with OSGi

In a nutshell, I believe the foundations of OSGi are solid but it wasn't built for mass application development. It introduces friction into the development/deploy process that is already fraught with challenges. I'd like to see the OSGi spec leads focus more on the developer/user persona of OSGi to make it invisibile to the development process. Also I'm appalled that the JVM still doesn't have a transparent module standard.

Answer 4

Most of our applications are web applications.

We have one OSGi thick client that gathers biometric information. Photographs and fingerprints through fingerprint card scanning, currently.

The advantage of OSGi to us is that we can update the plug-ins from a central web site, rather than using an uninstall / install process. Our thick client will be in over 100 locations throughout the United States, so this was important to us.