The OSGi Framework
OSGi defines a dynamic module system for Java. The OSGi service platform has a layered architecture, and is designed to run on various standard Java profiles.
OSGi Applications deployed to WebSphere Application Server run on an Enterprise Java profile provided as part of the server runtime environment. This environment also provides the OSGi framework in which OSGi Applications run. Eclipse Equinox is the reference implementation of the OSGi Service Platform Release 4 Version 4.2 Enterprise Specification, and WAS uses Equinox as the framework for OSGi Applications. The precise version of Equinox depends on the service level of WAS.
Modules layer
The unit of deployment in OSGi is a bundle. The modules layer is where the OSGi Framework processes the modular aspects of a bundle. The metadata that enables the OSGi Framework to do this processing is provided in a bundle manifest file. For more information about this file, see Example: OSGi bundle manifest file.
One key advantage of OSGi is its class loader model, which uses the metadata in the manifest file. There is no global class path in OSGi. When bundles are installed into the OSGi Framework, their metadata is processed by the module layer and their declared external dependencies are reconciled against the versioned exports declared by other installed modules. The OSGi Framework works out all the dependencies, 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:
- Each bundle provides visibility only to Java packages that it explicitly exports.
- Each bundle declares its package dependencies explicitly.
- Packages can be exported at specific versions, and imported at specific versions or from a specific range of versions.
- Multiple versions of a package can be available concurrently to different clients.
Lifecycle layer
The bundle lifecycle management layer in OSGi enables bundles to be dynamically installed, started, stopped, and uninstalled, independent from the lifecycle of the application server. The lifecycle layer ensures that bundles are started only if all their dependencies are resolved, reducing the occurrence of ClassNotFoundException exceptions at run time. If there are unresolved dependencies, the OSGi Framework reports them and does not start the bundle.
Each bundle can provide a bundle activator class, which is identified in the bundle manifest, that the framework calls on start and stop events. In this way, a bundle can provide special initialization and cleanup code if required, although most OSGi applications deployed to WAS should not need to do so. If a bundle needs a template bundle activator, we can use IBM Rational Application Developer v8.5 to generate one.
Services layer
The services layer in OSGi intrinsically supports a service-oriented architecture through its non-durable service registry component. 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 implemented using one of the following supported component models:
- A Blueprint-managed bean.
- An enterprise bean.
An OSGi service is 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 can look up a service in the service registry by an interface name, and can potentially filter the services that are being looked up based on the custom properties.
Services are fully dynamic, and typically have the same lifecycle as the bundle that provides them. OSGi Applications in WAS usually interact with the OSGi service registry through a Blueprint module definition. POJO bean components described in the Blueprint module definition can be registered as services through a <service> element, or can have service references injected into them through a <reference> element.
Related:
Business goals and OSGi Applications The modularization challenge Enterprise OSGi standards The WebSphere programming model and OSGi Developing an OSGi application OSGi Alliance - Technology: The Framework OSGi Service Platform Release 4 Version 4.2 Enterprise Specification Example: OSGi bundle manifest file
File name: was335.html
prettyPrint();