OSGi Application Design - Am I Abusing a Service Frame?

Question

In the application under development, I have a common interface for the data provider components to implement, and I connect these providers to the services.

One of my colleagues suggested that it would be better to just create one service that can track these implementations (how much is currently available and, possibly, make them available to other parts of the code base via getters), and we could register / cancel them use with activators of implementation packages.

While this usually works, this is (almost) exactly what the level of service provides, in the first place, and it seems to me that we are duplicating functionality.

What do you think?

Answer 1

This will be a duplication of functionality. Your service for managing other existing services becomes a service registry.

Now you have services that depend on your data providers, also depending on your service manager, and only so that they can search to get the actual service that they need.

It’s better to just insert the actual required dependency into the code that actually needs it, and there are many tools (DS, Spring DM, Blueprint ...) that will provide this functionality based on the capabilities defined in the specification, That is, the utility registry.

Update. If you are doing dynamic loading, as you mean, OSGi already provides a ServiceListener for this purpose, and consumers should be aware of this nature and encoded accordingly. The above tools also handle these cases.

Answer 2

Your use case is one of the main uses of OSGi for registry services. The service registry was mainly intended for such applications where you need to split instances between unrelated modules.

Using the service registry, you get:

• Tools such as declarative services or Blueprint that let you not get attached to the OSGi API.
• Triathlon
• Introspection
• Concurrency
• Any module can contribute to the pool without requiring central configuration changes.
• Possibility of a choice with the help of a powerful filter (operating time is configured using DS)
• Debugging with existing shells
• Unified

The main goal of OSGi has always been independent modules that provide services to other users, such as the whiteboard programming model. This provides a very elegant peer-to-peer model of decoupled programming. All the class pressures of wars have always overshadowed this aspect.

Answer 3

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

hope this helps you