The OSGi(Open Services Gateway initiative) framework provides a dynamic modular architecture which has been used in many applications such as Eclipse Equinox, Apache Felix, etc. Understanding how OSGi framework works is useful for developing Eclipse plugins and many other molecularity applications. In this article, the high-level overview of the architecture is explained.
OSGi framework architecture consists three conceptual layers. Each layer is dependent on the layer(s) beneath it. The diagram below describe the overview of each layer.
Module layer
Module layer defines OSGi module concept – bundle, which is a JAR file with extra metadata. A bundle contains class files and related resources such as images, xml files.
Through manifest.mf metadata file, Module layer declare which contained packages in JAR file are visible to outside, and declare on which external packages the bundle depend.
Some metadata examples:
Export-Package: com.programcreek.helloexport
It declares which packages are visible to users.
Import-Package: com.programcreek.helloimport
It declares when external packages are required.
Lifecycle layer
This layer defines how bundles are dynamically installed and managed in the OSGi framework. It provides a way for a bundle to gain access to the underlying OSGi framework.
If OSGi were a car, module layer would provide modules such as tire, seat, etc, and the lifecycle layer would provide electrical wiring which makes the car run.
Service layer
In this layer, service providers publish services to service registry, while service clients search the registry to find available services to use.
This is like a service-oriented architecture (SOA) which has been largely used in web services. Here OSGi services are local to a single VM, so it is sometimes called SOA in a VM.
* Some of the content are from book “OSGi in Action”.