Provisioning and resolution - Enterprise OSGi in Action - page 182

Blueprint bean representing a service from the Service Registry. Just as Blueprint ser-
vices make good capabilities, Blueprint references can be turned into requirements,
as shown in the following listing.

Listing 7.7 A Blueprint reference definition

<reference id="reference"
interface="fancyfoods.offers.SpecialOffer"
availability="optional"
filter="(open=true)">
</reference>
Once again, the Blueprint XML snippet provides you with all the information you
need to build a requirement, in this case the required service interface, and an LDAP
filter expression that can easily be turned into the requirement's filter. Importantly,
there are a few other pieces of information contained within this XML snippet that
allow you to determine the directives, as well as the attributes, that you should add to
this requirement.
The easiest directive to spot from listing 7.7 is the availability directive. In this case,
your Blueprint reference is optional, which can be communicated to the resolver eas-
ily. The second directive is somewhat more difficult to spot because there's no attri-
bute that corresponds to it. It's the element itself that defines it. Because you're using
a reference element, you're looking for a single service instance. This means that
your Requirement object should have a cardinality of single .
REQUIRING MULTIPLE SERVICES
As you may remember, in Blueprint it's possible to require multiple services with the
same service interface. This is done using the reference-list element. The reference-
list element is similar to the reference element, and again provides an excellent way
to model service dependencies, as can be seen in this listing.

Listing 7.8 A Blueprint reference-list definition

<reference-list id="ref-list"
interface="fancyfoods.offers.SpecialOffer"
availability="mandatory"
filter="(open=true)">
</reference-list>
In listing 7.8, you can see that the attributes for your Requirement will be exactly the
same as the attributes for listing 7.7. The directives, however, will be different. In
listing 7.8, your Requirement is now mandatory not optional , and because this is a
reference-list element, the Requirement must have multiple cardinality .
Now that you've seen how bundles can be modeled to support provisioning by
package and by service, it's time to take a look at some of the technologies that can be
used to provision bundles at runtime.