Open Services Gateway initiative framework (OSGi)
1. What is OSGi ?
OSGi is a specification. The core of the OSGi specification defines a component and service model for Java. The components and services can be dynamically activated, de-activated, updated and de-installed.
A very practical advantage of OSGi is that every bundle must define its exported Java packages and its required dependencies. This way you can effectively control the provided API and the dependencies of your plug-ins.
OSGi bundles:
The OSGi specification defines the OSGi bundle as the unit of modularization.
A bundle is a cohesive, self-contained unit, which explicitly defines its dependencies to other modules and services. It also explicitly defines its external API.
Technically OSGi bundles are .jar files with additional meta information. This meta
information is stored in the "META-INF" folder in the "MANIFEST.MF" file.
bundle = identity & dependency info + jar
The "MANIFEST.MF" file is part of a standard jar specification to which OSGi adds additional metadata. Any non-OSGi runtime will ignore the OSGi metadata. Therefore OSGi bundles can be used without restrictions in non-OSGi Java environments.
Bundle-SymbolicName and Version:
Each bundle has a symbolic name which is defined via the Bundle-SymbolicName property. and a version number in the Bundle-Version property.
The Bundle-Version and the Bundle-SymbolicName uniquely identifies a bundle in OSGi.Both properties are defined in the "MANIFEST.MF" file.
Bundle dependencies and public API:
Via the "MANIFEST.MF" file a bundle can define its dependency to other bundles or packages. OSGi will throw a ClassNotFoundException, if a class from a bundle tries to access a class without a defined dependency to it.
In the MANIFEST.MF file a bundle also defines the Java packages which should be exported and therefore available to other bundles (as API). Packages which are not exported are not visible to other bundles.
All these restrictions are enforced via a specific OSGi classloader. Each bundle has its own classloader. Access to restricted classes is not possible, also not via reflection.
A bundle can define that it depends on a certain version (or a range) of another bundle, e.g. bundle A can define that it depends on bundle C in version 2.0, while bundle B defines that it depends on version 1.0 of bundle C.
Bundle Lifecycle:
With the installation of a bundle in the OSGi runtime this bundle is persisted in a local bundle cache. The OSGi runtime is then trying to resolve all dependencies of the bundle.
If all required dependencies are resolved the bundle is in the status "RESOLVED" otherwise it is in the status "INSTALLED".
If several bundles exist which would satisfy the dependency, then the bundle with the highest version is taking. If the versions are the same, then the bundle with the lowest ID will be taken. If the bundle is started, its status is "STARTING". Afterwards it gets the "ACTIVE" status.
OSGi offers the following advantages:
Reduced complexity: Developing OSGi means developing modules ie bundles. They hide their internals from other bundles and the communication is through well defined interfaces.Hence the later changes can be easily accommodated without affecting other modules.
Reuse : The OSGi component model makes the integration of third party components very easy.
You can install, uninstall, start, and stop different modules of your application dynamically without restarting the container.
Your application can have more than one version of a particular module running at the same time.
OSGi provides very good infrastructure for developing service-oriented applications, as well as embedded, mobile, and rich internet apps.
Some of the currently popular implementations of the OSGi specs :
Apache Felix:
Eclipse Equinox
Knopflerfish
Popular application servers which use OSGi technology :
Weblogic – Oracle Weblogic Application Server
WebSphere – IBM Websphere JEE Application Server
REFERENCE:
No comments:
Post a Comment