OSGi application design - am I abusing the service

Question

In an application we're developing I have a common interface for data provider components to implement, and I'm hooking these providers up as services.

One of my colleagues suggested it might be better to just create one service that can keep track of these implementations (how many are available currently, and perhaps make them available to other parts of the codebase via getters), and we could register/deregister them using the implementation bundle's activators.

While this could generally work, this is (almost) exactly what's provided by the service layer in the first place, and to me, it feels like we're duplicating functionality.

What do you think?

Answer 1

you can check the page as follow：http://www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.html

hope it's help for you

Answer 2

Your use case is one of the primary OSGi use cases for the service registry. The service registry was primarily intended for this kind of applications where you need to share instances between uncoupled modules.

Using the service registry you get:

1. Tools like Declarative Services or Blueprint that allow you to not couple to OSGi API
2. Eventing
3. Introspection
4. Concurrency
5. Any module can contribute to the pool without require central configuration changes
6. Selectability with a powerful filter (runtime configurable with DS)
7. Debuggability with existing shells
8. Standardized

The primary purpose of OSGi has always been independent modules that contribute services for others to use, e.g. the blackboard programming model. This provides a very elegant peer-to-peer decoupled programming model. The whole class loading wars have always overshadowed this aspect.

Answer 3

That would be duplicating functionality. Your service to manage other services in effect becomes the service registry.

You now have any services dependent on your data providers also dependent on your service manager, and only so that they can do lookups to get the actual service they want.

Better to simply inject the actual required dependency into the code that actually needs it, and there are many tools (DS, Spring DM, Blueprint...) that will supply this functionality based on the capabilities defined in the specification. That is, the service registry.

Update: If you are doing dynamic loading, as you imply, then OSGi already provides a ServiceListener for this purpose, and consumers need to be aware of this nature and coded appropriately. The afore mentioned tools handle these cases as well.