We've covered a lot of ground in this chapter. Some of the highlights include the
Modularity is a form of separation of concerns that provides both logical and
physical encapsulation of classes.
Modularity is desirable because it allows you to break applications into logically
independent pieces that can be independently changed and reasoned about.
Bundle is the name for a module in OSG i. It's a JAR file containing code,
resources, and modularity metadata.
Modularity metadata details human-readable information, bundle identifica-
tion, and code visibility.
Bundle code visibility is composed of an internal class path, exported packages,
and imported packages, which differs significantly from the global type assump-
tion of standard JAR files.
The OSG i framework uses the metadata about imported and exported packages
to automatically resolve bundle dependencies and ensure type consistency
before a bundle can be used.
Imported and exported packages capture inter-bundle package dependencies,
but uses constraints are necessary to capture intra-bundle package dependen-
cies to ensure complete type consistency.
From here, we'll move on to the lifecycle layer, where we enter execution time aspects
of OSG i modularity. This chapter was all about describing bundles to the OSG i frame-
work; the lifecycle layer is all about using bundles and the facilities provided by the
OSG i framework at execution time.