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

also introduced after the first draft of this topic was complete. This is the challenge of
writing about exciting emerging technologies!) Subsystems implementations are
being developed as we write, but it will take time for them to be finished. We expect
support for plans, PAR s, Karaf features, and EBA s will continue for some time, even
after portable subsystems implementations have been released.

4.3 The Enterprise Bundle Archive (EBA)

Apache Aries defines a concept similar to the ESA called the Enterprise Bundle Archive
( EBA ) . The design of the EBA was one of the principal inspirations for the subsystems
specification. If you understand subsystems, you'll understand a lot about EBA s by
swapping the word subsystem for the word application . EBA s are packaged in .eba files,
and the metadata is defined in an optional APPLICATION.MF file.
The headers are similar as well. For example, the core content of an EBA is
selected using the Application-Content: header in the application manifest:

Application-Content: fancyfoods.web;version="[1.1.0,2.0.0)",
fancyfoods.department.chocolate;version="[1.0.0,2.0.0)"
Like ESA s, EBA s may use a version range for the content bundles. Although ESA s can
nest other ESA s, EBA content is restricted to bundles. The implications of being listed
in the Application-Content: header are also different for EBA s.

4.3.1 Sharing and isolation

Although in general EBA s are similar to ESA s, one area where they differ significantly
is scoping and isolation. Whereas ESA s offered lots of flexibility in terms of how con-
tent was scoped—with applications, features, and composites as precanned variants—
options for EBA s are more limited.
As well as minimizing the amount of extra information that you need to supply
when writing the metadata, the Application-Content: header has an important role
to play in the structure of an enterprise OSG i application. The application content
represents the core of an application, and will include API s and services that the mod-
ules use to communicate with each another, but that aren't intended for public use. In
Java EE this is accomplished by completely separating all parts of the applications.
Enterprise OSG i could do the same thing by creating a separate OSG i framework for
each application, but this would prevent any level of sharing or reuse within the run-
time, essentially eliminating many of the advantages you switched to OSG i for in the
first place!
Laying out the guts of your application for all the world to see isn't a good idea, but
you don't want to hide everything else that could be shared, either. Fortunately, in enter-
prise OSG i you don't have to do either. The Application-Content: header of an EBA
also defines the isolated content of the application. Isolated content is about as simple
as it sounds; the isolated bundles can see each other, but can't be seen by shared bundles
or by other applications. The clever part is that, because of the loose coupling that OSG i
provides, the isolated bundles can still import packages from the shared bundles. This