Java Reference
In-Depth Information
composition is the deployed set of components. For
the application to execute, the application's constitu-
ent components must somehow be loaded into the
component framework and instantiated. Figure 11.1
shows a trivial component composition.
This description of component orientation is by
no means complete. Depending on the component
model, components may have a variety of capabili-
ties, such as explicit lifecycle control. Some compo-
nent models and frameworks differentiate between
component types and instances (for example, there
can be multiple component instances from a given type), whereas others treat them as
being the same (only one instance per component). You'll see some of these differ-
ences rear their heads in our later discussions of specific
OSG
i-based component
frameworks. For now, it's sufficient if your general understanding of component ori-
entation is as a programming approach promoting coarse-grained, composable appli-
cation building blocks. Now let's look at why we want it.
Foo
FooImpl
Bar
Bar 1..1
BarImpl
Figure 11.1
Trivial component
composition of two components:
FooImpl
and
BarImpl
11.1.2
Why do we want components?
The long-held promise of component orientation is that we'll be able to create appli-
cations easily and quickly by snapping them together from readily available, reusable
components. The actual merits of this rosy view of component orientation are debat-
able, but there are benefits to be gained by adhering to a component model. First and
foremost, it promotes separation of concerns and encapsulation with its interface-
based approach. This enhances the reusability of your code because it limits depen-
dencies on implementation details.
Another worthwhile aspect of an interface-based approach is substitutability of
providers. Because component interaction occurs through well-defined interfaces, the
semantics of these interfaces must themselves be well defined. As such, it's possible to
create different implementations and easily substitute one provider with another. You
may have noticed that these benefits are pretty much the same as we described for
OSG
i services. This is part of the reason why such a strong synergy exists between
OSG
i
and component technologies; more on this shortly.
Because component models typically make the provided and required interfaces
of components explicit (or at least explicitly focus on them), you end up with more
reusable software that's amenable to composition. And because component models
typically require a specific pattern or approach for development, your code ends up
more uniform and easier to understand. This uniformity also leads to another poten-
tial benefit: external management.
This last point isn't necessarily obvious; but by creating components following a
specific model, external entities can understand more about your code and poten-
tially take some tasks off your hands. For example, transactions and persistence are
handled automatically for components in
EJB
. Another example is distribution,
