Reference Guide

Providing Services with OSGi Declarative Services
The OSGi standard component framework, called Declarative Services [33], is used to create
component-oriented applications. It is called declarative because there is no need to write explicit
code to publish or consume services.
A component describes functional building blocks that are typically more coarse-grained than
what we normally associate with objects.
These building blocks are typically business logic; they provide functionality via interfaces.
Conversely, components may consume functionality provided by other components via their
interfaces. A component framework is used to execute components.
A component model describes what a component looks like, how it interacts with other
components, and what capabilities it has (such as lifecycle or configuration management). A
component framework implements the runtime needed to support a component model and execute
the components.
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 compose them (match
required interfaces to provided interfaces) to form an application. Component compositions can
be declarative, such as using some sort of composition language to describe the components and
bindings among them.
By using components applications can be created easily and quickly by snapping them together
from readily available, reusable components. Components promote separation of concerns and
encapsulation with its interface based approach. This enhances the reusability of your code
because it limits dependencies 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.
The type of component model defined by OSGi is called service-oriented component model which
rely on execution-time binding of provided services to required services using the service-oriented
interaction pattern [33].
Continuing with the example, the SwitchService from the Service API on page 156 will be
published via SwitchManager from the Service Implementation on page 157 so it is available to
be consumed by other components.
SwitchManager is a Java object not bound by any restriction other than the service interface it
implements and those forced by the Java Language Specification; similar to a POJO [19]. Since
OSGi declarative services require a component to be annotated and to implement some methods
to bind/unbind other dependency components, a proxy component will be introduced (that
follows the proxy pattern [34]) to deal with OSGi allowing the business logic to be separated from
the OSGi restrictions. The following listing shows the OSGi service component used to publish
SwitchService via OSGi declarative services. The implementation of the OSGi component should
also be located in the hm-bl module.
159