OSGi application design - am I abusing the service framework? [closed]

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

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.