1.2. Deployment Models

Although Red Hat JBoss Fuse 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.1, “Alternative Deployment Packages” shows an overview of the package types associated with each deployment model.

Figure 1.2, “Installing an OSGi Bundle” gives an overview of what happens when you install an OSGi bundle into the Red Hat JBoss Fuse container, where the bundle depends on several other bundles.

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 Chapter 13, Deploying Features).

Figure 1.3, “Installing a FAB” gives an overview of what happens when you install a typical FAB into the JBoss Fuse container (where it is assumed that all of the FAB's dependencies are either FABs or plain JARs).

After you install the FAB into the Red Hat JBoss Fuse 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 1.4, “Installing a WAR” gives an overview of what happens when you install a WAR into the JBoss Fuse container.

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).