Although Fuse ESB Enterprise is an OSGi container at heart, it supports a variety of different deployment models. You can think of these as virtual containers, which hide the details of the OSGi framework. In this section we compare the deployment models to give you some idea of the weaknesses and strengths of each model.

Table 1 shows an overview of the package types associated with each deployment model.

Figure 2 gives an overview of what happens when you install an OSGi bundle into the Fuse ESB Enterprise container, where the bundle depends on several other bundles.

Figure 2. Installing an OSGi Bundle

Implicitly, a bundle shares all of its dependencies. This is a flexible approach to deployment, which minimizes resource consumption. But it also introduces a degree of complexity when working with large applications. A bundle does not automatically load all of its requisite dependencies, so a bundle might fail to resolve, due to missing dependencies. The recommended way to remedy this is to use features to deploy the bundle together with its dependencies (see Deploying Features).

Figure 3 gives an overview of what happens when you install a typical FAB into the Fuse ESB Enterprise container (where it is assumed that all of the FAB's dependencies are either FABs or plain JARs).

Figure 3. Installing a FAB

After you install the FAB into the Fuse ESB Enterprise container, the runtime analyzes the metadata embedded in the FAB and automatically installs the requisite dependencies by pulling them from your local Maven repository (or, if necessary, by downloading them from a remote repository).

Figure 4 gives an overview of what happens when you install a WAR into the Fuse ESB Enterprise container.

Figure 4. Installing a WAR

The WAR has a relatively simple deployment model, because the WAR is typically packaged together with all of its dependencies. Hence, the container usually does not have to do any work to resolve the WAR's dependencies. The drawback of this approach, however, is that the WAR is typically large and it duplicates libraries already available in the container (thus consuming more resources).