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

are nestable collections of bundles with a shared lifecycle. The subsystem contents can
be packaged into an archive with a .esa extension, and so we'll refer to them as Enter-
prise Subsystem Archives ( ESA s) .
Like an EAR , an ESA contains metadata describing the contents of an application
and how it should be deployed; however, unlike an EAR , the metadata for an ESA uses
a configuration by exception model, and so is entirely optional. Even the metadata
file may be omitted if no defaults need to be changed.
There are three distinct kinds of subsystems: applications, features, and composites.
All represent collections of bundles, but how permeable the boundaries are varies.

4.2.1 ESA structure

One of the most important details about an application packaging model is the struc-
ture it places on the application. If the structure is too loose or complex, then the
applications are usually hard to generate, requiring special tools, or they become
impossible to understand for anything but simple examples. On the other hand, if an
application's structure is too rigid, then it can end up being rather cumbersome and
inflexible. The latter has plagued the EAR file format, requiring large monolithic files
with redundant metadata.
In many senses, an ESA file is a lot like an EAR file. An ESA is a zip format archive
that contains metadata in the form of an application manifest, and it also contains
OSG i bundles in the root of the zip archive. An ESA file does differ from an EAR in
structure in two key ways:

Unlike an EAR file, the metadata for an ESA doesn't need to be complete. Every
piece of ESA metadata has a default value that'll be used unless it's overridden.
This defaulting is so extensive that the metadata for an ESA may be omitted
entirely if the defaults are acceptable.

■

As we mentioned in section 4.1.1, an EAR almost always contains the entire con-
tent of the application, including shared libraries. An ESA can contain all the
bundles needed to run the application but, commonly, only a small subset of
the bundles that make up the application are included in the ESA . The remain-
ing bundles are then provisioned from a bundle repository when the applica-
tion is installed. We'll talk about this more in section 4.2.5.

■

As you can see from figure 4.2, the structure of an ESA is similar to an EAR , but
because the ESA doesn't need to package all of its dependencies, the file is much
smaller. In addition, the reduced number of modules in the ESA makes it simpler to
understand—there are fewer unimportant dependencies to wade through.
Although the metadata is optional in general, it's important to support applica-
tions that don't contain all their modules.