Java Reference
In-Depth Information
where some component frameworks automatically make components remotely acces-
sible. And as you'll see in this chapter, execution-time dependency management is
also possible.
This all sounds useful, but are there any downsides to using components? Yes, there
are always issues to be considered in any architectural decision. Table 11.1 details some
general issues you should consider when choosing whether to use components.
Table 11.1
Potential issues associated with component orientation
Problem
Description
Analysis
Bloat
Some component frameworks are relatively
heavy, so they may not be appropriate for
small applications.
How complex are your application dependen-
cies? Is the extra functionality provided by a
component framework required?
Diagnosis
Debugging service-dependency problems
requires a new set of tools to figure out
what's going on when your services aren't
published as expected.
Debugging dependency problems is often
simplified by having generic tools that can
be applied to common component models.
Side-file
syndrome
Build- or execution-time problems caused by
component configuration files becoming
stale with respect to Java source code can
be frustrating to debug.
IDE tooling can definitely help by providing
refactoring support and early analysis. A
number of projects are building in support of
component models, and they will only
increase over time.
Overall, we feel the positives far outweigh the potential negatives. Given this general
motivation for component orientation, let's move on to discussing how all this relates
specifically to
OSG
i.
11.2
OSGi and components
For those reading between the lines in the last section, it may not come as a complete
surprise, but there's a reason why the synergy between
OSG
i and component technol-
ogies is so strong. The core
OSG
i specification defines a component model and the
framework for executing the corresponding components. Yes, that's right:
OSG
i devel-
opers are component developers. The type of component model defined by
OSG
i is a
special kind, called a
service-oriented component model
. Let's take a minute to look at the
specification in this new light.
11.2.1
OSGi's service-oriented component model
The high-level description of the
OSG
i component model can be understood by
equating bundles with components and services with component interfaces. We'll put
a little more meat on this description by breaking down how the
OSG
i core specifica-
tion maps to the component-oriented concepts of the last section.
COMPONENTS AND THEIR INTERACTION
For a bundle to be a component, it implements a bundle activator. The activator also
allows for lifecycle management. Another capability includes external configuration
