Provisioning and resolution - Enterprise OSGi in Action - page 165

and an expert. Now, adding in the more detailed understanding of OSG i packaging
you learned in chapter 5 and armed with your Service Registry experience from chap-
ter 6 we're ready to discuss provisioning and resolution in more detail.
OSG i provisioning and resolution is covered by the OSG i Resource API Specifica-
tion, the Resolver Service Specification, and the Repository Service Specification. His-
torically, these specifications were part of a single OSG i Bundle Repository
Specification (often known as OBR ). These specifications explain how bundles should
be described, how dependencies between bundles are resolved, and how resolvers
interact with bundle repositories, and describe a text format for representing bundle
repository metadata. Although they define the standards for provisioning and resolu-
tion in OSG i, there are several other popular systems that also allow bundles to be
automatically downloaded and installed based on analysis of their dependencies.
Let's return to the world of provisioning and resolution by considering what gets
provisioned and resolved—how do you tell the provisioner about your bundles?

7.1 Describing OSGi bundles

You already know that OSG i bundles contain a lot of metadata describing themselves.
Metadata describes a bundle's dependencies, the packages it exposes to the outside
world, the bundle's name and version, and more. As you've seen in section 5.1.2, some
of a bundle's metadata has metadata of its own; Import-Package and Export-Package
allow packages to be decorated with attributes and either version ranges or versions,
respectively. This metadata is rich with information, most of which is used by the OSG i
framework resolver to determine whether a bundle is able to load classes.
As you learned in chapter 4, provisioning and resolution are closely related. That
this processed information is necessary in the resolution process means that it's also
critical for provisioning. When attempting to resolve a partially complete dependency
graph, a resolver may need to query a bundle repository to fill in the missing depen-
dencies. To answer these questions from the resolver, a bundle repository must be
able to describe the bundles it has to offer by modeling them, including all the infor-
mation needed by the resolver.
If the resolver and the repository are to agree in their descriptions of bundles,
then they need a common definition for describing OSG i bundles and their interac-
tions with the outside world. This common description is provided in OSG i by
the Resource API Specification through the use of generic Resource , Capability ,
and Requirement objects. Together these form a model for bundles—and lots of
other things!

7.1.1 Describing bundles as resources

In the generic sense, a Resource is a vague object. A Resource can represent any-
thing, from a binary or text file to a web service, an OSG i bundle, or something
more bizarre like a treacle sponge pudding! The key details about a Resource object
are as follows: