OSGi is a mature, lightweight, component system that solves many challenges associated with medium and large scale development projects. Through the use of bundles complexity is reduced by separating concerns and ensuring dependencies are minimally coupled via well defined interface communication. This also promotes the reuse of components in much the same way that SOA promotes the reuse of services. And, since each bundle effectively is given an isolated environment, and since dependencies are explicitly defined, versioning and dynamic updates are possible. These are just a few of the many benefits of OSGi. Users wishing to learn more should check out http://www.osgi.org/Main/HomePage.
Before you can install an application into an OSGi container, you need to package it into one or more OSGi bundles. An OSGi bundle is a JAR that contains extra information that is used by the OSGi container. This extra information specifies the packages this bundle exposes to the other bundles in the container and any packages on which this bundle depends.
Fuse Services Framework applications should work in any OSGi container. However, they are only supported in the following containers:
Fuse ESB 4.0
4.0.0.3
Equinox 3.4.0
Before you can install an application into an OSGi container it needs to be packaged into one or more OSGi bundles. An OSGi bundle is essentially a standard JAR. Where an OSGi bundle and a plain JAR differ is in the contents of their manifest files. An OSGi bundle's manifest contains a number of properties that specify the following:
the Java packages which this bundle exposes to other bundles
the Java packages, and other resources, on which this bundle depends
the version number of the bundle
Applications in an OSGi environment are subject to the lifecycle of its bundles. Bundles have six lifecycle states:
Installed — All bundles start in the installed state. Bundles in the installed state are waiting for all of their dependencies to be resolved, and once they are resolved, bundles move to the resolved state.
Resolved — Bundles are moved to the resolved state when the following conditions are met:
The runtime environment meets or exceeds the environment specified by the bundle.
All of the packages imported by the bundle are exposed by bundles that are either in the resolved state or that can be moved into the resolved state at the same time as the current bundle.
All of the required bundles are either in the resolved state or they can be resolved at the same time as the current bundle.
![[Important]](imagesdb/important.gif)
Important All of an application's bundles must be in the resolved state before the application can be started.
If any of the above conditions ceases to be satisfied, the bundle is moved back into the installed state. For example, this can happen when a bundle that contains an imported package is removed from the container.
Starting — The starting state is a transitory state between the resolved state and the active state. When a bundle is started, the container must create the resources for the bundle. The container also calls the
start()method of the bundle's bundle activator when one is provided.Active — Bundles in the active state are available to do work. What a bundle does in the active state depends on the contents of the bundle. For example, a bundle containing a JAX-WS service provider indicates that the service is available to accept requests.
Stopping — The stopping state is a transitory state between the active state and the resolved state. When a bundle is stopped, the container must clean up the resources for the bundle. The container also calls the
stop()method of the bundle's bundle activator when one is provided.Uninstalled — When a bundle is uninstalled it is moved from the resolved state to the uninstalled state. A bundle in this state cannot be transitioned back into the resolved state or any other state. It must be explicitly re-installed.
The most important lifecycle states for application developers are the starting state and the stopping state. The endpoints exposed by an application are published during the starting state. The published endpoints are stopped during the stopping state.
 |  |  |
 |
