Hello all, I have used OSGI in a few projects, most recently in a research prototype for a sensor network data collection thingy.
Overall, I think OSGI is not hugely complex and provides some useful features. However, overall my feelings are a bit mixed. So I would like to ask others, what are your experiences in using OSGI vs other platforms. Some more specific experiences from my viewpoint: -Automated updates (or support for them) are commonly mentioned as something supported by OSGI. I see there is some basic support for this in loading/unloading services and bundles in the standard container. Additionally, there are things like Apache ACE that are commonly mentioned to take it further. But I fail to see how this really helps much, the big issue for me comes to transferring state from old services to new ones and managing all the dependencies between the elements as change is rarely localized. While I have needed to support updates, I find it is easier to just deploy a complete new version and restart the software. -Service code is separated by OSGI through different classloaders. For me this has been really nice in keeping dependencies from spreading and forcing me to think about component boundaries in a more focused way. But running an OSGI container just for this seems a bit heavyweight for me. The classloader separation also causes some big issues for me such as sharing libraries over services, such as web-services frameworks, where managing configuration files across services is just extra hard when the classloaders are separated, in addition to the usual OSGI classloader issues. When libraries are better supported, such as the Felix HTTP service with Jetty, it seems nice but actually is a wrapper that hides the configuration options under layers of abstraction (added complexity) that hide the more advanced configuration options from me and makes it hard if possible at all to use them. -Managing the framework and my application becomes more complex as the user has to understand the container caches, large number of directories, libraries, configuration files, etc. Things like configuring my app to run as a unix daemon are much more complex to manage and debug as I am not in direct control over the platform. Errors in application startup from remote deployments are harder since they are shown mainly in Felix and not in my application log files. -Using OSGI for me is a form of a local-level service abstraction (SOA). I have basically used Java interfaces to define the "interface" of each OSGI service. But this eliminates the navigation support my IDE in terms of static analysis and adds, what seems to me, unnecessary abstration. This is probably my failure in using too many interfaces but it feels to me as a "common practice" for OSGI apps. I was also looking for some support to hook and trace service interactions, which could justify some of this, but there is nothing like this. -Integration testing is difficult due to all the wiring required to get the overall system running. In simple cases it works OK with my own MockBundleContext, and the SOA approach makes the component composition even cleaner in this regard. However, in more complex interactions starting the whole container becomes a big burden for me. Overall, the approach of SOA at local level seems great for the overall architecture. But it seems to me currently there are just too many issues for me, and for that reason, I would prefer a more simple approach. Maybe I am just doing wrong or building wrong types of apps. Any other experiences? Thanks for your thoughts, Teemu
