Managing applications - OSGi in Action - page 320

With these tools, you'll be better equipped to build, deploy, and configure sophisti-
cated OSG i-based applications. Let's start by looking at bundle deployment.

10.1 Deploying bundles

When you've created some configurable bundles and versioned them according to a
meaningful policy, you need to install them into an OSG i framework. In chapter 3, we
looked at the various details of the lifecycle layer API , which allows you to install, start,
update, and uninstall bundles from a running framework. Given the nature of modu-
larity, it's likely your applications will grow over time to include too many bundles for
you to manage their deployment in an ad hoc fashion. Manually installing and updat-
ing tens, hundreds, or even thousands of bundles becomes impractical. What can you
do? This is when it becomes important to think about how you (or your users) are
going to discover and deploy bundles.

10.1.1 Introducing management agents

The solution, in OSG i lingo, is to create a specific type of bundle called a management
agent . Although we've shown how to programmatically manipulate the lifecycle of a
bundle, it's typically not a good idea for a bundle to change its own state or the state of
other bundles. Such a bundle is difficult to reuse in other compositions, because it's
tightly bound to the other bundles it expects to control. The solution employed by
most management agents is to externalize the information about which bundles to
install or start. For example, management information can refer to bundles using
URI s and aggregate useful groups of bundles using some sort of composition lan-
guage/mechanism. A management agent can generically process such information,
leaving it nicely decoupled from the bundles it's managing.
A simple example of a management agent is the shell from chapter 3. Granted, it's
perhaps too simplistic because it only accepts and executes commands; but if such
capabilities are sufficient for your application, it's fine. A management agent can be
much more powerful, however. Even for your shell, you could easily extend it to han-
dle command scripts for executing commands in batches. You could then create a
couple of scripts, one for each configuration you need. Switching between application
configurations would then be trivial.
More sophisticated management agents are possible. Your shell assumes human
interaction to either directly or indirectly make the correct decisions and issue com-
mands to manage the bundles. You could devise a system with rules to automate some
of this by reacting to certain conditions autonomously. Consider a home-automation
system that's able to detect a new device, automatically discover a driver for it in a
remote repository, and subsequently install the driver along with its dependencies. Or
you may have an application that automatically adapts itself to the language of the cur-
rent user by installing the necessary locale bundles.
In essence, a management agent manages a running framework. OSG i supports
you in developing such an agent by providing you with the means to monitor and