Java Reference
In-Depth Information
process is called
bundle resolution
and involves matching exported packages to imported
packages. Bundle resolution ensures consistency among bundles with respect to ver-
sions and other constraints, which we'll discuss in detail in chapter 2.
LIFECYCLE LAYER
The lifecycle layer defines how bundles are dynamically installed and managed in the
OSG
i framework. If you were building a house, the module layer would provide the
foundation and structure, and the lifecycle layer would be the electrical wiring. It
makes everything run.
The lifecycle layer serves two different purposes. External to your application, the
lifecycle layer precisely defines the bundle lifecycle operations (install, update, start,
stop, and uninstall). These lifecycle operations allow you to dynamically administer,
manage, and evolve your application in a well-defined way. This means bundles can
be safely added to and removed from the framework without restarting the applica-
tion process.
Internal to your application, the lifecycle layer defines how your bundles gain
access to their execution context, which provides them with a way to interact with the
OSG
i framework and the facilities it provides during execution. This overall approach
to the lifecycle layer is powerful because it lets you create externally (and remotely)
managed applications or completely self-managed applications (or any combination).
SERVICE LAYER
Finally, the service layer supports and promotes a flexible application programming
model incorporating concepts popularized by service-oriented computing (although
these concepts were part of the
OSG
i framework before service-oriented computing
became popular). The main concepts revolve around the service-oriented publish,
find, and bind interaction pattern: service providers publish their services into a ser-
vice registry, while service clients search the registry to find available services to use
(see figure 1.6). Nowadays, this service-oriented architecture (
SOA
) is largely associ-
ated with web services; but
OSG
i services are local to a single
VM
, which is why some
people refer to it as
SOA
in a
VM
.
The
OSG
i service layer is intuitive,
because it promotes an interface-based
development approach, which is gener-
ally considered good practice. Specifi-
cally, it promotes the separation of
interface and implementation.
OSG
i
ser-
vices
are Java interfaces representing a
conceptual contract between service
providers and service clients. This makes
the service layer lightweight, because ser-
vice providers are just Java objects
accessed via direct method invocation.
Additionally, the service layer expands
Service
registry
Publish
Find
Service
description
Service
provider
Service
requester
Interact
Figure 1.6
The service-oriented interaction
pattern. Providers publish services into a registry
where requesters can discover which services are
available for use.
