OSGi in a Nutshell: What is OSGi? (continued)
In the previous post of the series we started with a simple definition of OSGi, as an additional layer which can be put on top of Java, and provides a set of functionalities to help you develop an application as a *modular* and *dynamic* system.
We also looked into the first keyword, modular. This week is time for the second one, dynamic.
Dynamic
We live in a dynamic world, that’s out of question, right?
Conditions can change quite rapidly, people and things come and go, what is available today may not be available tomorrow and vice versa.
Well, the world of applications is no difference. The connection between a client and a server may be lost at any point and for any reason, and what was possible one second before can become unavailable. In the same way, a service may depend on the presence of a second service to work, and we maybe not even need a service if another one is not available. Think about the weather. If it is sunny you do not need to take your umbrella with you, so you do not even care if the umbrella is where it is supposed to be. On the other hand, if you wake up in the morning and it’s raining cats and dogs, then you probably wish to find your umbrella before leaving for work!
Java cannot handle such a dynamism on its own. When you launch your application, all the classes on the class path are loaded and they are available since the beginning.
OSGi, on the other hand, is able to reflect the dynamic needs of an application. Services can come and go, you can make a service depending on the presence of another service, so if and when the second service becomes unavailable for some reasons, then also the first one is deactivated. In this way you can notify, for instance, in advance that a certain operation is no longer possible because the service is not available, instead of encountering an Exception an runtime because you are trying to do something which is not possible anymore.
This may sound complicated at first. Believe me, it was complicated for me as well (it still is, sometimes). But if you think a moment about it, it makes perfect sense. Why should I keep a service around if it is no longer needed? Or why should I have a service there if it depends on a service which cannot currently perform its work because, let’s say, the connection to the database has not been established yet?
In the same way, the OSGi framework allows you to dynamically handle not only a single service lifecycle, but also a whole bundle lifecycle, in the sense that you can install, update, stop and remove bundles from a running OSGi framework. This is not possible with a plain Java environment. Once a class is in the class path, it is loaded when the JVM is started and if you want to remove it, you need to stop the application, remove the class from the class path and restart the application again.
This concludes our brief introduction on OSGi and its two main characteristics. I hope to have you intrigued enough to follow also the next posts, where we will enter the details of some simple use cases, to see in a more practical way what you can achieve with OSGi!
by Ilenia Salvadori