Provisioning and resolution - Enterprise OSGi in Action - page 172

this requirement. Despite being so important, the filter directive is almost always
generated programmatically (the framework generates them for bundles), so it's
unlikely that a user would ever have to write one.
We've spent a reasonable amount of time looking at how bundles can be modeled
programmatically using the OSG i Resource Specification, and how this fits into the
OSG i resolver service, but we haven't explained how these fit together with provision-
ing. We're now ready, however, to look at provisioning using the OSG i Repository Ser-
vice. One of the key aspects of the OSG i Repository Service is hinted at in its name, the
repository . Repositories are a vital part of provisioning; without a repository it's not pos-
sible to provision anything in a meaningful sense.

7.1.4 Repositories

Modeling bundles is an important job for an OSG i resolver, and it's critical that the
framework understand the relationships between OSG i bundles so that they can be
resolved. This information isn't just important to a framework resolver, but is also nec-
essary in provisioning. A repository is a standard place in which bundles can be
located and, if necessary, downloaded and installed. As the collection of OSG i bundles
within your enterprise grows, you'll almost certainly need a repository to store your
bundles and allow applications to be provisioned against them. You may also want to
make use of a number of publicly available repositories (more on public repositories
in section 7.4.1).
Repositories make use of exactly the same Capability and Requirement interfaces
as the resolver, which makes it easy for them to interoperate. Although a resolver is
capable of large-scale complex dependency analysis, a repository can only provide
responses to simple queries, listing the capabilities that match a supplied requirement.
On the other hand, although a typical repository can contain a large variety of resource
types, a resolver can typically only understand a limited number of resource types. For
example, a framework resolver is only required to understand OSG i bundles.
REPOSITORY SERVICES AT RUNTIME
Repositories serve an important function at runtime. When the resolver is asked to
determine whether a set of bundles can resolve or not, it makes use of an Environ-
ment . You can compare the Environment or a Repository to a helpful waiter in a res-
taurant that's run out of menus. You might want to eat steak, or to order something
served with asparagus. To find out what was available, you'd ask the waiter if they had
any steak or asparagus on the menu. When the resolver comes across a dependency, it
does more or less the same thing; it queries the environment for resources that
expose particular capabilities. The resolver then attempts to determine the correct res-
olution for the bundles. Depending on how deep the dependency graph is (whether
you want side dishes), this may involve further queries to the environment. The link
between the environment and repositories is that the environment can be used to join
the current state of the framework (the bundles that are already installed) with one or
more repositories. This allows additional bundles to be dynamically provisioned into a
system as necessary (see figure 7.6).