Why should one create & use services in OSGi

Question

I have been studying OSGi for past week but the sole reason doesn't seem to fit right that why do I need to register and use any bundle when I can do it by simply importing its JAR file. What benefit do I achieve by doing so? Yea sure, I do get the dependency management but:

can I use any other JAR files by importing them which are not registered as services itself? If yes, why should I take the overhead of using OSGi?

Answer 1

The problem services solve is the binding problem that emerges when you start with contract based programming. In your code you are using an interface but in runtime you actually need an implementation object for that interface. How to get this?

Services are an incredibly elegant solution to do this binding problem, all other solutions I know have leaky abstractions and, when analyzed, are not modular. Some people point at XML based solutions but they only seem to make this coupling go away, under the surface the coupling and its bad side effects still exist.

The hard decoupling is the primary advantage of services, and would be worth it alone.

However, once you start using services and see how easy it is to work with them (in Declarative Services), they become a primary architecture and design primitive. You start to compose systems out of services instead of code, they become the hinges that make your system flexible and maintainable. Show me a service diagram of your system and I tell you not only what your system does (unlike most high level architecture pictures that are uncannily similar between wildly different systems), but I can also tell you how to extend it. Also, the close integration of configuration management and the service model provides unsurpassed flexibility to the people deploying the system.

Services solve lots of problems that many developers consider the cost of doing business, i.e. intricate problems that are part of life. Solutions to these problems require an effort to understand because people often feel there is no problem. In mediaeval times cities had no sewage systems but they also did not miss it. You only miss it, once you've had it.

That said, not everything is a service. If the API + implementation are the identical then by all means, use libraries. For example, the ASM library is clearly a library that should be used directly but something as Quartz should be behind a service.

Answer 2

The whole idea of OSGi is that you get modularity: clear separation of concerns and functionality with the option to replace or update the functionality with a different version or implementation when needed.

By importing a jar you can instantiate a class declared in an other jar, but you cannot replace it (runtime!) by another implementation or version. The idea with OSGi services is that you define a Java interface and use this interface from the client by looking up its implementation in the OSGi service registry without the client actually being aware of the implementation of the interface. This makes it possible to replace the implementation with another version or even totally different solution at runtime with little concern for the client. That is just impossible by instantiating a class from another jar.

Of course, if you don't need that, you may think that OSGi is just a lot of overhead. You may be right, depending on your situation. I found that following the structure of OSGi gives you better awareness of the relation between the components and the overall architecture of your application. A great benefit from maintenance perspective.