OSGi services - best practice

Question

I start loving OSGi services more and more and want to realize a lot more of my components as services. Now I'm looking for best-practice, especially for UI components.

For Listener-relations I use the whiteboard-pattern, which IMHO opinion is the best approach. However if I want more than just notifications, I can think of three possible solutions.

Imagine the following scenario:

interface IDatabaseService {
  EntityManager getEntityManager();
}

[1] Whiteboard Pattern - with self setting service

I would create a new service interface:

interface IDatabaseServiceConsumer {
  setDatabaseService(IDatabaseService service);
}

and create a declarative IDatabaseService component with a bindConsumer method like this

protected void bindConsumer(IDatabaseServiceConsumer consumer) {
 consumer.setDatabaseService(this);
}
protected void unbindConsumer(IDatabaseServiceConsumer consumer) {
 consumer.setDatabaseService(null);
}

This approach assumes that there's only one IDatabaseService.

[Update] Usage would look like this:

class MyUIClass ... {

private IDatabaseService dbService;

Consumer c = new IDatabaseServiceConsumer() {
 setDatabaseService(IDatabaseService service) {
  dbService = service;
 }
}
Activator.registerService(IDatabaseServiceConsumer.class,c,null);
...
}

[2] Make my class a service

Image a class like

public class DatabaseEntryViewer extends TableViewer

Now, I just add bind/unbind methods for my IDatabaseService and add a component.xml and add my DatabaseEntryViewer. This approach assumes, that there is a non-argument constructor and I create the UI components via a OSGi-Service-Factory.

[3] Classic way: ServiceTracker

The classic way to register a static ServiceTracker in my Activator and access it. The class which uses the tracker must handle the dynamic.

Currently I'm favoring the first one, as this approach doesn't complicated object creation and saves the Activator from endless, static ServiceTrackers.

Answer 1

I have to agree with @Neil Bartlett, your option 1 is backward. You are in effect using an Observer/Observable pattern.

Number 2 is not going to work, since the way UI objects lifecycles are managed in RCP won't allow you to do what you want. The widget will have to be created as part of the initialization of some sort of view container (ViewPart, Dialog, ...). This view part is typically configured and managed via the Workbench/plugin mechanism. You should work with this, not against it.

Number 3 would be a simple option, not necessarily the best, but simple.

If you use Spring DM, then you can easily accomplish number 2. It provides a means to inject your service beans into your UI Views, Pages, etc. You use a spring factory to create your views (as defined in your plugin.xml), which is configured via a Spring configuration, which is capable of injecting your services into the bean.

You may also be able to combine the technique used by the SpringExtensionFactory class along with DI to accomplish the same thing, without introducing another piece of technology. I haven't tried it myself so I cannot comment on the difficulty, although it is what I would try to do to bridge the gap between RCP and OSGi if I wasn't already using Spring DM.