Component models and frameworks - OSGi in Action - page 362

The possible cardinality values defined by the Declarative Services specification are 0..1
(optional, singular dependency), 1..1 (mandatory, singular dependency), 0..n
(optional, aggregate dependency), and 1..n (mandatory, aggregate dependency).
From the snippet, you can see that the paint frame has an optional, aggregate depen-
dency on shape services; this means it wants to be bound to all available shape services,
but doesn't need any to function. Cardinality is fairly straightforward, but the depen-
dency policy is a little trickier to understand.
A component service dependency can be declared with either of two policy values:
dynamic or static. What does this mean? A dynamic policy means that the component
is notified whenever the service comes or goes, whereas with a static policy, the service
is injected once and not changed until the component is deactivated. In essence, if you
use a dynamic policy, your component needs to cope with the possible issues (such as
threading and synchronization) resulting from service dynamism. If you use a static pol-
icy, you don't need to worry about issues related to service dynamism, but your compo-
nent sees only one view of the services published in the OSG i registry while it's active.
This dependency policy also relates to component lifecycle management. For
example, the paint frame component specifies a dynamic policy. Therefore, if a shape
it's using goes away, it sees the change immediately and dynamically adapts accord-
ingly. You've seen this in earlier examples, where you dynamically added and removed
shapes. If this dependency were specified as static, then if a shape service being used
by the paint frame departed, the paint frame component instance would need to be
thrown away, because a static policy means the component isn't programmed such
that it can handle service dynamism. We'll continue this discussion about component
lifecycle in the next subsection.
Another characteristic of service dependencies is a target filter. To illustrate, let's
look at the WindowListener component of the modified paint program; its Declara-
tive Services component description is as follows.

Listing 11.4 Metadata for WindowListener with optional LogService dependency

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
name="windowlistener">
<scr:implementation class="org.foo.windowlistener.WindowListener" />

<scr:reference
name="window"
interface="java.awt.Window"
policy="static"
cardinality="1..1"
target="(name=main)"
bind="bindWindow"
unbind="unbindWindow"/>
<scr:reference
name="logService"
interface="org.osgi.service.log.LogService"
policy="dynamic"

B Window service
dependency

Specifies
filter

C