views:

246

answers:

2

Hi, I have a scenario where during the system install time, a few services were deployed on to the OSGi container and these services will be listening for other bundles that provide data and are dynamically installed and uninstalled at runtime.

These data providers do not expose any services and should not even invoke services; my idea is to enable the pre-deployed services to listen for the event of installation of these data provider bundles and if the pattern matches, then process and persist the data into the data store.

For example I have a WidgetService which will listen for installation or uninstallation event of Widget data provider bundles, ShppingCartService that will listen for the installation/uninstallation events from ShoppableItem data provider bundles, etc.

This helps me to keep the processing and persisting logic be centralized and my data providers need not write any code to make their data processed. All that is expected from the data provider bundles is the Service Name/id, Service Version,PreRequisites, and the data that they need to publish.

I have read several articles on OSGi that explain dynamic pluggability of services and the clients able to discover or discard services based on their availabity; however, those are all talking about scenarios where clients are to be intelligent to discover and execute the services they are interested in.

My intention is to make client completely unaware of any service discovery, for that matter any code. All that the client passes is the info about the service the client is interseted in, the dependencies, and the data; the client should be completely dumb.

Is this possible in OSGi? I'm ready to consider this architecture even at the cost of extending a few of the OSGi core framework classes!

I have found some what, may be, remotely related question on stack overflow at : Discovering Bundle MetaData with out installing the bundle

However, I want a hook or an event that will call my respective service when one or more data provider bundles have been installed. These data provider bundles can be interested in any of the services that are installed in the system. I'm even ready to write a central bunle repository manager/listener kind of stuff that will listen to any bundle installation and invoke my Service facade that will decide which service to execute based on the meta data provided by the data provider bundle.

I'm just starting OSGi, so need a little direction on how to move forward...

I'll be really thankful to you guys/girls :) if you can help me achieve this!

I have a doubt deep in my mind that this may not be readily available in OSGi, and even if that is true I'm ready to spend time and extend the framework to achieve this. All I need is a few guidelines and a clear direction. Who knows, if OSGi is really lacking this functionality, then it would be a very useful add-on to a future OSGi spec.

I hope I get some help from OSGi community,

Thanks and Regards, Samba

+1  A: 

You might have a look at section 4.7 (Events) of the OSGi Core spec. The Framework raises BundleEvents when there is a change in the lifecycle of a bundle, e.g. when it is installed or uninstalled. What you need to do is to implement a BundleListener, which then will receive the events, so your service can react on the changes.

akr
Saasira
In general, you are right. The listener pattern is discouraged in OSGi. But this concerns only listeners between bundles, not listeners you register with the framework. The BundleListener is actually a service that follows the white board pattern, ie. you don't register a listener with you other bundle. This way there is only a very loose relationship between your components.For your other question: no, there is no "event repository". But don't worry, the events are only calls to registered services. And this is something an OSGi implementation should handle well.
akr
Thanks a lot for your help, AKR! Now I'm confident that I can achieve my intended design in OSGi with out any tweaking. Another interesting feature that I came across a while ago is that Apache Felix OSGi implementation has a BundleTracker similar to ServiceTracker utility that will publish addingBundle(),modifiedBundle(), and removedBundle() callbacks like the ServiceTracker does. I'm not sure if this is an OSGi standard interface, or a Felix extention. I'll be really thankful to you if you can clarify whether the BundleTracker utility is an OSGi standard or not! Thanking you, Samba
Saasira
You are welcome. Yes, the BundleTracker is part of the standard. Have a look at the Companion spec, chapter 701.4 . You should download the OSGi specs from the OSGi web side (www.osgi.org). The spec is actually quite readable and has many implementation examples :-)
akr
A: 

I have described a design pattern that I call "OSGi Mediator", which may be a solution to your problem.

The items you want to mediate would only require to register with the service registry; all the dependencies could be managed by your mediator implementation.

Dieter