Java Reference
In-Depth Information
all your dependencies to rank themselves. More seriously, what should the ranking
even be? Can you be sure that every consumer of the services will agree on the same
relative ranking? Should a faster service implementation be ranked highest, or a more
reliable one? Sometimes a clear ranking of services is possible—for example if one ser-
vice wraps another one and is intended to supersede it—but more often, different ser-
vices are...different.
Being choosy about services
Although it's usually easy to distinguish services, it's also worth remembering that a
well-designed application shouldn't normally need to. If you've done things right, then
any service in the list should be up to the job.
Sometimes the differences between services can be an issue; happily, these differences
can be expressed using service properties. You can identify your service precisely by
adding specific service properties to it. As it does for other parts of the service
API
,
Blueprint offers some handy
XML
for adding properties to a service:
<service ref="specialOffer"
interface="fancyfoods.offers.SpecialOffer">
<service-properties>
<entry key="magic.word"
value="Abracadabra"/>
String service
property
<entry key="magic.number">
<value type="java.lang.Integer">
42
</value>
</entry>
</service-properties>
</service>
When you have some service properties to pick from, you can tie down your choice of
service tightly by using a service filter in your Blueprint
XML
. Filters can be used to
pick services with certain properties:
Typed service
property
<reference interface="fancyfoods.offers.SpecialOffer"
filter="(magic.number=42)"/>
If you want to lock down your service usage completely you could even set the imple-
mentation name as a service property and filter on it. This drastically increases cou-
pling between bundles and we definitely don't recommend it! The risk of this strategy
is that if no available service satisfies your filter, you'll be left with none at all. The
more specific your filter, the greater the risk. In general, you should choose service
properties that express something about the contract the service satisfies (for exam-
ple,
is.transactional=true
), rather than ones that are unique to one particular ser-
vice (such as
vendor=SomeCorp
). Filters are extremely powerful and use the full range
of syntax allowed by the
LDAP
filter specification. If you're keen to use filters in your
