OSGi is a specification describing dynamic modular system for java platform. Essentially, two key aspects here – dynamic modules called bundles in OSGi and the OSGi runtime facilitating these bundles.
More details on OSGi can be found here.
Dynamic modules – Bundles
- Bundle represents an unit of deployment that implements highly cohesive, loosely coupled functionality.
- Bundle explicitly states its dependencies.
- Bundles are versioned.
- Bundles allow hiding information at package level.
- Classpath per bundle.
- Each bundle has a name called ‘symbolic name’ for its unique identity.
Dynamic modular system – OSGi runtime.
- Allows bundles to be installed, started, stopped, configured at run time.
- Allows bundle to collaborate with each other to meet its dependencies.
- Bundle with different versions can co-exist at run time. Solves JAR hell.
- Classloader per bundle.
A glimpse of goodness we gain with this dynamic modular setup in OSGi.
You can think of your application as a set of modules. Each module can be installed, started, stopped, configured at the runtime without any restart. If one of your module fails, only the dependent modules will be impacted; rest of your application can work fine. Your module could refer multiple versions of the dependent module. You’ve the options to hide your implementations within the module. All these are feasible with OSGi dynamic module setup.
To make all these possible, OSGi defines lifecycle of bundles and go with latebinding (runtime binding) . The need for late binding for meeting dependencies at runtime spawns the dynamic component model in OSGi.
Learn more on OSGi design patterns including basics on OSGi trail.