Component models and frameworks - OSGi in Action - page 350

management using BundleContext.getProperty() , although the exact details are
left to the framework implementation.
The bundle JAR file is the independent unit of deployment for a component. In
OSG i, the logical bundle (the component) is equated with the physical bundle JAR file
(the module). Technically, this means there can be only one component per module
and, further, only one component instance. Later, you'll see that most OSG i-based
component frameworks break this one-to-one physical-to-logical mapping, but this
mapping isn't the important part of the OSG i component model. OSG i's killer feature
is in the richness of its dynamic module layer. Some component models and frame-
works deal with modularity (the code level), but few if any provide such rich features.
At the module level, as you've learned, bundles have a way of explicitly describing
the code they provide and require. At the component level, the core OSG i specifica-
tion doesn't define a way for bundles to explicitly declare the services they provide
and require. Instead, these issues are left to be handled manually by the bundle at
execution time.
COMPONENT FRAMEWORK
The distinction between component model and framework is definitely blurred in the
OSG i specification, because it goes to great lengths to ensure that the component
framework has standardized behavior. This ultimately makes aspects of what might
ordinarily be thought of as belonging to the component framework part of the com-
ponent model.
The OSG i-based component frameworks described here and in the following chap-
ter can be seen as extensions to the OSG i component model and framework. This is
sometimes confusing because the distinction of what is part of the model, the frame-
work, or components themselves isn't always obvious. For example, the OSG i Configu-
ration Admin Service defines how bundles can be configured. But it isn't part of the
OSG i component model, nor the OSG i component framework; it's an agreement
among the Configuration Admin component and its client components.
But this is how it should be. Keep the model and framework simple and small. Try
to do everything else in the layers above. The framework should be the execution
environment for components and little else.
COMPONENT COMPOSITION
Just as there isn't an explicit way for bundles to declare their provided and required
services, the core OSG i specification doesn't define an explicit way to compose an
application. In OSG i, the composition of a component-based application is the set of
deployed bundles. The interesting part is how the composition is constructed (match-
ing provided services to required services), which is done at execution time via the ser-
vice registry. This service-oriented interaction pattern among components is what
makes the OSG i approach a service-oriented component model.
Using execution-time service binding means dependencies are resolved late. Fur-
ther, the use of an interfaced-based interaction via services enables substitutability of
providers. Combining late binding and provider substitutability results in a flexible