OSGi for Beginners

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:

http://www.osgi.org
http://www.eclipse.org/equinox
http://felix.apache.org

java.lang.IllegalStateException: "Workbench has not been created yet"

I’ve been working with OSGi for quite awhile and have faced a problem "Workbench has not been createt yet" issues. I was getting this error, When i was trying to run OSGI plugin from Eclipse and I guess many of you must have face this problem. So i am writing a little bit about how to resolve this issue so others don’t repeat the same mistakes.

From a good article on eclipsezone:

java.lang.IllegalStateException: Workbench has not been created yet

This usually comes when someone tries to run a Java application against an OSGi bundle with java -classpath .... . It really means that the workbench plug-in hasn't started yet, and so calls to getWorkbench() fail. This is essentially a race condition, and can be solved by either expressing an explicit dependency on that bundle or bumping up that bundle to a higher start level than the workbench. Generally not seen, but if it is, that's what's happening.

Now to set the bundle to a higher start level than the workbench.
Select your manifest.mf, right-click, select Run As-> Run Configuration. Create a OSGi Framework launch configuration. Deselect all bundles except your bundle. Change the default set level to higher level and Press then "Add Required bundles"
Run this configuration. This should give you the correct output.

If you still get the same error ,then you can do
1. Add the -clean to the program Arguments.i,e(Run Configuration->OSGI framework->Arguments ->program Arguments)

                                           OR (Recommended 1 if failed then try 2)
2. Delete the .metadata folder which is created by default in Eclipse Workspace but before that please take the backup..:)




Hope its gonna work for you guys too..Feel free to comment.