Component models and frameworks - OSGi in Action - page 351

Service-oriented component models
Service-oriented component models rely on execution-time binding of provided servic-
es to required services using the service-oriented interaction pattern (publish-find-
bind). Often, execution-time dynamism is also associated with service-oriented com-
ponent models, but this isn't technically a requirement to receive some of the bene-
fits. For example, COM follows a similar approach of execution-time binding to
required components, but it doesn't assume that these components will also come
and go during application execution. Still, following this approach allows you to treat
the deployed set of components as the application configuration, which leads to flex-
ibility in your application composition.

component model where compositions are malleable, because they don't specify
explicit component implementations, nor precise bindings among them. In the OSG i
model, this also opens up the possibility of advanced scenarios based on execution-
time dynamism.
The OSG i approach is flexible, but it's also a little low-level. For example, although
OSG i uses an API -based approach, many modern component models use or are mov-
ing toward an API -less approach, such as using Plain Old Java Objects ( POJO s) as com-
ponents. This has led to the creation of several OSG i-based component frameworks
and/or extensions to the core OSG i approach. In the next section, we'll provide an
overview of what these additional component frameworks are trying to achieve.

11.2.2 Improving upon OSGi's component model

The main weakness of the OSG i component model is its reliance on components man-
ually managing their own service-level dependencies, even though module-level
dependencies are automatically managed. Some of the earliest work on improving the
OSG i component model was done to address this complexity, such as by Beanome
( www.humbertocervantes.net/papers/ ISADS 2002.pdf ) and Service Binder ( www.hum-
bertocervantes.net/papers/ ESEC 2003.pdf ) . All of the component frameworks we'll
discuss in this chapter and the next also address this issue. Because the approaches
have a lot of similarities, we'll try to describe some of the issues in a general way here.

GENERAL APPROACH
OSG i-based component frameworks adopt the bundle JAR file as the deployment unit
for components. In general, they break the “one component per JAR file” approach of
the standard OSG i component framework and allow any number of components to be
contained in it. They all define additional, component-related metadata, which is
packaged in the bundle to describe the components contained in the bundle JAR file.
They then employ the extender pattern to listen for bundles containing components
to come and go so they can start managing the contained components, as shown in
figure 11.2. A component's description defines which services it provides and which it
requires; we'll go into a little more depth on this topic shortly.