OSGi architecture

The core part of the OSGi Service Platform defines a secure and managed service platform that is based on Java™. This platform supports the deployment of extensible and downloadable applications that are known as bundles. The specification defines a security model, an application lifecycle management model, a service registry, an Execution environment, and Modules.

OSGi defines a dynamic module system for Java. The core OSGi Service Platform has a layered architecture, and is designed to run on various standard Java profiles. OSGi introduces the notion of a bundle as a modular unit, and the platform architecture is based on bundles as the unit of deployment. The OSGi architecture has the following layers:
Execution environment layer
Module layer
Lifecycle layer
Service registry layer
For more information about OSGi architecture, see the core OSGi service platform specification.

Execution environment layer

The execution environment layer specifies the Java environment (for example, Java EE or Java SE) under which a bundle runs. For OSGi applications that run in WebSphere® Application Server, you do not need to specify the execution environment.

Module layer

The module layer is where the OSGi Framework processes the modular aspects of a bundle. The metadata that enables the OSGi Framework to process the bundle is set in a bundle manifest file.

One of the key advantages of OSGi is its class loader model, which uses the metadata in the manifest file. OSGi does not have a global class path. When bundles are installed into the OSGi Framework, the metadata is processed by the module layer and the declared external dependencies are reconciled against the versioned exports declared by other installed modules. The OSGi Framework determines the dependencies by using the manifest, and calculates the independent required class path for each bundle. This approach resolves the shortcomings of plain Java class loading by ensuring that the following requirements are met:
  • Only packages that are explicitly exported by a particular bundle, through the metadata, are visible to other bundles for import.
  • Each package can be resolved to specific versions.
  • Multiple versions of a package can be available concurrently to different clients.

Lifecycle layer

The bundle lifecycle management layer in OSGi eliminates the problem with Java class loading and the class not found exception at run time, in which dependant classes cannot be loaded because they cannot be found. When an installed bundle is deployed into the framework, the framework first resolves all of its declared dependences. If there are unresolved dependences, the framework reports these dependences and does not start the bundle.

In the bundle lifecycle:
  • Bundles are dynamic, and can be started and stopped independent of the rest of the framework.
  • Each bundle can provide a bundle activator that the framework calls on start and stop events. The bundle activator is declared in the bundle manifest.

Applications typically do not need to provide a bundle activator. However, if initialization is required when the bundle starts or stops, a bundle activator can be created.

Service registry layer

The service registry layer in OSGi intrinsically supports service-oriented architecture (SOA). Bundles publish services to the service registry, and other bundles can discover these services from the service registry.

These services are the primary means of collaboration between bundles. An OSGi service is a Plain Old Java Object (POJO), published to the service registry under one or more Java interface names, with optional metadata stored as custom properties (name-value pairs). A discovering bundle looks up a service in the service registry by an interface name, and then can potentially filter the services by using the custom properties.

Services are fully dynamic and typically have the same lifecycle as the bundle that provides them.

Icon that indicates the type of topic Concept topic
Timestamp icon Last updated: July 17, 2017 21:58

File name: cosgiarchitecture.html