OSGi Service Model is limited

2 04 2009

I don’t want to sound negative, but as always when you look past the hype and read the detail some of the truth comes out. Take OSGi Configuration Service. On the face of it this would allow each service to have its own configuration and allow you to bring a service up and let is manage everything. Well to an extent that is true, provided you adopt the ManagedService model. This means that OSGi manages all the services for you, you define what you want to be configured by using constants within your code or creating an xml file defining he configuration constants, and OSGi takes care of the rest. Sounds pleasant enough, and allows changes in configuration to be listened to by the components. Update the config, and its reflected in the component. So this works perfectly well for a single component with a single service impl exposing a single api, but as soon as your bundle contains a collection of services implementations that are constructed with IoC, then none of the services can be managed. In short the ManagedService places a boundary around the service implementation that prevents it from communicating with other services except via static instances, or something horrible.

The impression that you could use the OSGi Configuration Service at run-time or in a cluster is somewhat mistaken. So I have 5 OSGi JVM’s in my cluster, and I change the config on one of them, magically the ManagedServices notice the change and reconfigure, but what about the other nodes in the cluster that now have a different configuration ?

And then there is the use case where we have configuration information that really shouldn’t be changed when a bundle is active. A database connection. Change that mid stream, who knows what will happen.

At the moment, unless anyone reading this can tell me how to use the configuration service where bundles expose multiple services, constructed by IoC, I feel its going to be simpler to create a ManagedService that is a configuration service, and allow that service to communicate throughout the cluster and manage reloading. Its a pity since I had hoped OSGi would manage this for me, perhaps I should have not trusted the hype again, reminds me of a belief in EJB many years ago.

Advertisements

Actions

Information

3 responses

2 04 2009
Stuart Freeman

I’m not as familiar with the internals of OSGi, but a little bit of web searching led me to http://code.google.com/p/peaberry/ and I wonder if it addresses any of the issues mentioned above.

2 04 2009
Ian

Yes certainly looks possible, we have a similar import semantic but the export semantic is quite clean. We might consider it if longer term there are requirements that we cant cover. The only thing I can see that is slightly worrying is that the library appears to require 2 threads, perhaps per bundle. One for the dynamic nature of the registry, and one for the internal implementation of the ConcurrentReferenceHashMap. Since we already have this in Google Collections and Guice, and both of those share a single finalizer thread per JVM, I dont really want to add more threads. Unfortunately most of the impl is final, so it will be hard to fix without forking.

16 05 2009
Stuart McCulloch

FYI: only one (optional) thread is used inside peaberry to clean up unused service references – this lets you control how often unused services are released rather than releasing them after every single call, which could be very expensive if you call them frequently . This same one thread is used regardless of how many client bundles you have.

You can disable this thread by setting the “org.ops4j.peaberry.cache.interval” property to a negative value. You’d then get similar behaviour to Spring-DM.

There are no other threads in peaberry – the ConcurrentReferenceHashMap implementation (from JBoss’ experimental JSR166y library) doesn’t use any internal threads.

By default we mark the implementation as final to avoid people accidentally depending on the internals (there’s a public API you can use to provide your own registry implementations) but we’re also willing to listen to suggestions for improvements 🙂




%d bloggers like this: