Fuse ESB Enterprise's OSGi framework is the runtime that implements and provides OSGi functionality. It provides the execution environment for OSGi-based applications deployed into it.
The OSGi framework consists of three layers:
The module layer is responsible for managing bundle packaging, resolving dependencies, and class loading.
Internal to an application, the lifecycle layer defines how bundles access their execution environment, which provides them the means to interact with the OSGi framework and the facilities the framework provides during runtime.
The service layer, employing the publish, find, and bind service model, provides communication between bundles and the components they contain. It does so by providing an OSGi service registry where service providers register their services and where service requesters find and bind (get a reference) to them.
Fuse ESB Enterprise's kernel acts much like a mini operating system to create and manage a runtime
environment for a deployed application. It does so by setting up an execution environment
that meets the requirements specified in the MANIFEST.MF file included in each
bundle in an application. It then creates the resources each bundle needs by reading the
bundle's Blueprint or Spring XML file. If the bundle is a service provider and contains the
necessary publishing information, the kernel registers the service in the OSGi service
registry, so any service requester bundle that needs to use the registered service can find
and access it.
The kernel interacts with the Services layer to create the resources specified within an
OSGi bundle. For example, a service provider bundle that instantiates a message broker might
define two connections that use different transports, one HTTP and one JMS. The kernel
interacts with the messaging service to set up the message broker with the configuration
specified in the bundle's activemq.xml file and creates the required
transports.
Figure 2 shows the steps involved in
activating an example route bundle. A developer would create (1) and deploy (2) a route bundle into
Fuse ESB Enterprise's OSGi container. The route bundle would contain business logic (in this case a
RouteBuilder class written in Java code), an OSGi MANIFEST.MF
file defining the bundle's requirements (dependencies, imports, exports, and so on), and a
Blueprint.xml file defining the route's resources.
First, the kernel would read the bundle's MANIFEST.MF file (3) to set up the application's execution environment and resolve
bundle dependencies. Then it would read the bundle's Blueprint .xml
configuration file (4) to discover and set up the resources
needed for the route. The business logic's RouteBuilder class would access the
routing and integration service (5) via the OSGi service
registry to define the route's CamelContext (the routing
runtime).
In both cases, if the bundles were (2) hot deployed,
the configured message broker and the route would start up immediately after their resources
were in place. Otherwise, the developer or the system administrator would have to issue, at
the console command line, osgi:install and osgi:start commands for
each bundle.









