Packaging your enterprise OSGi applications - Enterprise OSGi in Action - page 93

EAR ; however, the EAR also has to include libraries and other dependencies and
describe them in the application.xml descriptor. Unlike an EAR , the core content of
an ESA need not (and usually doesn't) represent the complete set of bundles that
should be installed to run the application.
The core content of an ESA is selected using the Subsystem-Content: header in
the application manifest:
Subsystem-Content: fancyfoods.web;version="[1.1.0,2.0.0)",
fancyfoods.department.chocolate;version="[1.0.0,2.0.0)
Core content may be declared optional.
Aside from not specifying the complete set of modules, there's one other big dif-
ference between ESA metadata and EAR metadata. The content of an ESA subsystem
selects bundles using their symbolic name and an OSG i-style version range. This
means that the same OSG i subsystem may run different bundles over the course of its
life! Because the metadata has a degree of flexibility built in, it allows the application
to be updated with service fixes without being repackaged. This is a significant advan-
tage over the static model used by EAR s, which require a whole new application to be
generated for even a minor update. When selecting by version range, the bundle used
may be contained within the root of the ESA , like a module in an EAR file, or refer to a
bundle within a bundle repository. In fact, unlike a typical EAR file, it's likely that an
ESA file won't contain most of the modules that it needs. We'll discuss more about
bundle repositories, version ranges, and dependencies when we look at provisioning
and resolution, but first we should take a brief look at scoping and subsystem types.
SUBSYSTEM TYPES AND SCOPING
We mentioned earlier that there are three distinct types of subsystems: applications,
features, and composites. Application is the default, but other types may be selected
using a Subsystem-Type: header. For example, to declare a feature, the header would
be this:
Subsystem-Type: osgi.subsystem.feature
An application doesn't export anything to the outside framework, but its contents
have free access to the outside. A feature is designed for sharing, so it's totally
unscoped. Not only can its bundles see everything in the outside framework, the out-
side world can see all the bundles in the feature. A composite is a group of bundles
that behaves like a single bundle; everything is private to the composite unless explic-
itly exported, and external dependencies must be explicitly imported.
The type of a subsystem also affects how its content is handled. A feature has com-
plete visibility of the outside framework, so there's no need to add content inside the
feature beyond what's already included. Composites and applications are less porous,
and so it's meaningful to ask what's inside the subsystem and what's in the outside
framework. A provision-policy:=acceptDependencies directive may be added to
the Subsystem-Type declaration. This tells the system that explicit content and indi-
rect dependencies should be treated as part of the subsystem.