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 that is 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 WebSphere Application Server uses Equinox as the framework for OSGi Applications. The precise version of Equinox depends on the service level of WebSphere Application Server.
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.
- 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 that are deployed to WebSphere Application Server should not need to do so. If a bundle needs a template bundle activator, you can use IBM® Rational® Application Developer Version 8.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.
- A Blueprint-managed bean.
- An enterprise bean.
Services are fully dynamic, and typically have the same lifecycle as the bundle that provides them. OSGi Applications in WebSphere Application Server usually interact with the OSGi service registry through a Blueprint module definition. POJO bean components that are 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.