Component models and frameworks - OSGi in Action - page 347

(continued)
Component frameworks aren't constrained by the component model they support and
may provide additional capabilities. This is common when vendors try to differentiate
implementations of standard component models; think about how Java EE applica-
tion servers try to differentiate themselves. The reality is that no clear line separates
a component model from a component framework. The important differentiation to
take away is that a component model describes what it means to be a component,
and the framework provides the runtime to execute components adhering to a com-
ponent model.
Generally speaking, components have some explicit way of declaring their provided
interfaces. This can be done through certain patterns, such as implementing an inter-
face or extending a base class, or it can be done more explicitly at execution time by
publishing provided interfaces, such as using an interface repository. Likewise, com-
ponents may have some explicit way of declaring their dependencies on the provided
interfaces of other components, such as with declarative metadata, or they may be
responsible for managing their own dependencies at execution time, such as querying
an interface repository. Often, components are packaged as independent deployment
units, such as JAR files or DLL s, but this isn't strictly necessary.
Modules vs. components
Doesn't it sound like modules and components have a lot in common? They both pro-
vide stuff to each other and consume stuff from each other. They're also packaged
as independent deployment units. Couldn't these two be considered one and the same
or at least be combined? Yes, they could, but components and modules serve different
purposes and are somewhat orthogonal (they're not completely orthogonal, because
components are made from code that can ultimately be packaged into modules).
Modules deal with code packaging and the dependencies among code. Compo-
nents deal with implementing higher-level functionality and the dependencies
among components. Components need their code dependencies managed, but they
technically don't need a module system to do it (often it's us programmers doing it
via the class path).
A good summary is that you can think of modules as dealing with static code and
compile-time dependencies, whereas components deal with instances and execution-
time dependencies.
The general approach for creating an application from components is to compose it.
This means you grab the components implementing the functionality you need and com-
pose them (match required interfaces to provided interfaces) to form an application.
Component compositions can be declarative , such as using some sort of composition lan-
guage to describe the components and bindings among them; or implicit , where the