Stepping back, if content and dependencies aren't packaged up in the ESA
archive, where do they come from? So far you haven't seen anything in the application
manifest that shows how you cope when an ESA doesn't contain all the bundles it
needs. There's a good reason for this, which is that none of this information is stored
in the application metadata at all! To be run in an enterprise OSG i runtime, an ESA
needs to undergo a process called deployment , where two important things happen:
provisioning and resolution.
Provisioning and resolution
Provisioning and resolution are two different, but related, steps that are taken when
deploying an enterprise OSG i application. Though both steps can occur indepen-
dently, they're often performed simultaneously. Unfortunately, this often leads to
some confusion about the difference between provisioning and resolution, with many
people thinking the terms are interchangeable names for the same thing. For simplic-
ity's sake, we'll attempt to separate the two operations from one another as much as
possible; however, it will be pretty clear that the most useful applications will rely upon
the interplay between the provisioner and resolver. We'll also come back to provision-
ing and resolution in chapter 7.
Fundamentally, provisioning is a relatively simple operation, but because it isn't part
of the Java EE application model it's not immediately comfortable for many develop-
ers. Provisioning is a little more common in standard OSG i, but it's still not a process
that many OSG i developers would think about in detail. At its most basic, provisioning
is the operation by which modules are located and deployed into the correct location.
Because Java EE EAR s package all their modules inside themselves, provisioning
isn't necessary. The code needed to run the application is either available as a module
within the EAR or from the application server itself. Nothing needs to be fetched from
anywhere. As we've already discussed, ESA s are a bit different. Although an ESA may
contain all the modules it needs, it will more commonly refer to bundles that aren't
contained inside it. It won't be possible to run an OSG i application without having all
of the bundles that it needs, so as part of the ESA deployment process it's necessary to
locate and obtain any bundles that aren't already inside the ESA . This process typically
makes use of one or more bundle repositories to locate and download the bundles
that are needed (see figure 4.3).
For a typical enterprise OSG i application, one or more bundles will need to be down-
loaded as part of the deployment operation. This means that there needs to be some
way of uniquely identifying the bundle and finding out where it can be downloaded
from. Fortunately, OSG i provides a symbolic name for each bundle that, in conjunction
with a version, uniquely identifies a particular bundle. A simple bundle repository can
therefore be thought of as being a bit like an organized music store; you can search for
music by a particular artist, and then pick a particular song. The store will then present
you with a URL from which you can start downloading the song.