1. OSGi enforces modularity
Making systems modular feels good to every engineer. It is just a logical thing to do when systems grow. We define and design modules in our systems. But once implemented, they cannot be taken out or replaced by a better version because they get entangled so quickly. When coding OSGi style, this will not happen. Why? Read on.
2. OSGi defines module boundaries
One reason modularity is enforced is because you define a clear entrance point in your modules which is the interface to the rest of your system. No unclear API due to many public classes, but a well defined set of visible classes that were meant to be API. The rest is hidden, public or not public. Why is this handy?
3. OSGi helps you manage complexity.
Once you can see your modules as giant blocks of LEGO(tm) (having a clear interface) you can think about what the weak blocks are and how they can be replaced or hardened. Do all your work inside the module but be faithful to the interfaces with the outside world. This is how they build Skyscrapers.
Although it sounds to good to be true, true it still is. And even though OSGi sounds like a sneeze, it is all about the GESUNDHEIT of your applications.
We host an OSGi course in December. There are a few places left. Neil Bartlett will be your teacher. By the way, Neil did write the book, a free book and the eye opening first chapter is right here.
Apart from the course we will take you on a Amsterdam by Night tour where you will get a good, but not too good, impression of the unique Amsterdam culture. It is about 30 minutes drive from the training location to the center of Amsterdam.
See you there!
