1.2. Deployment Models
Overview
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.
Package | Metadata | Maven Plug-in | URI Scheme | File Suffix |
---|---|---|---|---|
Bundle | MANIFEST.MF | maven-bundle-plugin | None | .jar |
WAR | web.xml | maven-war-plugin | war: | .war |
OSGi bundle 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.
Figure 1.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 Chapter 8, Deploying Features).
WAR deployment model
Figure 1.3, “Installing a WAR” gives an overview of what happens when you install a WAR into the JBoss Fuse container.
Figure 1.3. 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).