LibraryToggle FramesPrintFeedback

How Fuse ESB Enterprise Activates a Deployed Bundle

Overview

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.

Bundle bootstrapping process

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.

Figure 2. Steps in activating a deployed route

Activation of a deployed route

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.

Comments powered by Disqus