Component models and frameworks - OSGi in Action - page 354

If the component's required services are satisfied, the component framework can
instantiate the component and publish its provided services into the service registry.
The descriptions of provided services are normally straightforward (just mentioning the
interfaces under which to publish the component), but the descriptions of required ser-
vices can be rich. A service's dependency description may include the following:
■ Service type —Actual type of required service
■ Optionality —Whether the dependency is mandatory or the component can
function without it
■ Cardinality —Whether the dependency is for a single service instance (one-to-
one) or for an aggregate number of service instances (one-to-many)
■ Lifecycle impact —Whether execution-time changes are visible to the component
(dynamic) or invalidate the entire component instance (static)
Most of these characteristics are reasonably self-explanatory. The last one, lifecycle
impact, is a little trickier. Because dynamism adds complexity, some component
frameworks allow components to control how much service dynamism a component
sees. If a component wants to treat a given dependency as having a static lifecycle, it
won't see new services arriving after instantiation and will be completely invalidated if
a service being used goes away. On the other hand, dependencies having a dynamic
lifecycle can potentially see (and handle) service dynamism at execution time without
being invalidated. For example, you may want to create a component with an
optional, dynamic dependency on a log service. If the log service isn't there, your
component can function without it; but if one arrives, your component can start using
it as soon as it's available.
Don't worry if these service dependency characteristics are a little fuzzy at this
point; they'll become clearer as we look into the various component frameworks in
more detail.
SIMPLIFYING OTHER MANAGEMENT AREAS
Another area where component frameworks can help in removal of boilerplate code
is in the management of component configuration. In chapter 9, you saw how you can
use the Configuration Admin Service to configure OSG i services using a simple porta-
ble model. Still, the developer must provide some boilerplate code to interact with
this service. Most component frameworks provide ways to simplify component config-
uration and interaction with the Configuration Admin Service.
Finally, a number of component frameworks allow for custom extension points to
allow third-party providers to provide advanced capabilities such as audit manage-
ment, persistent state, and transaction management using declarative hooks (either in
user code or via side files). These sorts of capabilities turn component frameworks
into rich programming environments, allowing you to strip away the layers and focus
your code on the core of your business process without sacrificing portability.
Having introduced component models and how they relate to modularity in gen-
eral and OSG i specifically, let's now turn our attention to a practical demonstration of
using component models and frameworks in OSG i.