Java Reference
In-Depth Information
better performance than Blueprint, although well-optimized implementations are
likely to show little measurable difference from one another. Like Blueprint, Declar-
ative Services uses
XML
to expose a managed object as an
OSG
i service, inject depen-
dencies, and chain services together. Also like Blueprint, managed objects are only
exposed as services if all of the services that they're injected with are also available or
have been marked as optional. Declarative Services also helps manage
OSG
i dyna-
mism, but unlike Blueprint it exposes you to more of the details.
Declarative Services doesn't have the same level of support as Blueprint for build-
ing and describing networks of managed bean instances within a bundle. In Declara-
tive Services, a managed component can easily be injected with a reference to a
service and exposed as another service (see figure 6.1), but, for example, it isn't possi-
ble to inject a component with another managed component that was created using
an arbitrary static factory method.
What's in a name?
Instead of Blueprint beans, Declarative Services describes managed classes in
terms of components and service components. For this reason, the Declarative Ser-
vices technology is often referred to as Service Component Runtime (SCR). When we
use the term
SCR
, we're referring to one implementation of Declarative Services, the
Apache Felix Service Component Runtime.
Like beans, service components may be wired to one another and optionally exposed
as services. Listing 6.4 shows the Declarative Services equivalent of listing 3.7. The
XML
file should be referenced from the bundle manifest using the
Service-Component
header. Wildcards can be used to pick up several
XML
files.
Declarative
Services
bundle
Declarative
Services
component
Figure 6.1
A bundle using Declarative Services to consume a service into a managed
component, which is then exported as a service itself
