Advanced component frameworks - OSGi in Action - page 401

For a component with a dynamic, aggregate dependency, i POJO adds services to
and removes them from the component at execution time as the associated services
appear and disappear in the service registry without invalidating the component
instance (in other words, the component instance lifetime spans service dynamism).
For a component with a static, aggregate dependency, i POJO injects the component
with a snapshot of the available services when the component instance was created.
i POJO doesn't inject later-arriving services; and if a service being used departs, i POJO
invalidates the component instance and throws it away (the component instance life-
time doesn't span service dynamism).
The main benefit of using static service dependencies is that your component code
is simpler because it never has to worry about dealing with dynamism; but, by default,
i POJO assumes service dependencies are dynamic. You can explicitly choose which
binding policy i POJO uses for a given service dependency. The possible values are
as follows:
■ static —Dependencies are treated as static.
■ dynamic —Dependencies are dynamic, but not with respect to service priority
(default).
■ dynamic-priority —Dependencies are dynamic and automatically change if a
higher-priority service appears, and/or aggregate dependencies are re-sorted.
The dynamic-priority policy uses the OSG i service ranking algorithm to determine
service priority, but i POJO also allows you to specify custom sorting algorithms based
on java.util.Comparator s. You declare the binding policy with the policy annota-
tion attribute on either @Requires or @Bind :
@Requires(policy=static)
private LogService m_log;
The binding policy should be determined on a case-by-case basis for each of your com-
ponent's service dependencies. This gives you pretty rich control over your compo-
nent's service dependencies, but sometimes this still isn't sufficient—for
dependencies that are potentially very short-lived, for example. For this, i POJO sup-
ports temporal service dependencies.
TEMPORAL SER VICE DEPENDENCIES
Service dependencies are generally mandatory (they must be satisfied to instantiate the
component) or optional (they aren't needed to instantiate the component). But some
types of service dependencies don't fit neatly into these two categories. For example,
perhaps your component needs a specific service during startup but then never needs
it again. Such a dependency can't be declared optional, because you need it at startup.
At the same time, if you declare it mandatory, and it goes away later, your component
instance will be invalidated even though it didn't need the service anymore.
In this scenario, the component only has a dependency on the service at a particu-
lar point in time. For this reason, i POJO supports temporal service dependencies,
which don't impact the overall component lifecycle like optional dependencies, but