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.
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.
- 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.
- 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.