Java Reference
In-Depth Information
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.
4.2.3
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.
PROVISIONING
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.
