Java Reference
In-Depth Information
Furthering their confusing nature,
Import-Service
and
Export-Service
weren't
expressive enough to describe the myriad of services that can be exposed in the Ser-
vice Registry. The big problem with these headers is that they have no way to type their
attributes (the service properties), and no way to specify multiple values for the same
property, either as an array or as a collection. Finally, the headers offered no way to
identify the optionality or cardinality of required services. All in all, the headers were
something of a disaster, which explains why they were removed from the specification.
Some people argue that, despite their shortcomings,
Import-Service
and
Export-
Service
are the only sensible way to model dependencies and should be used to build
Requirement
and
Capability
descriptions. Others argue that co-opting headers that
were (and still are) reserved by the
OSG
i alliance for something other than their original
purpose is a bad idea. For what it's worth, we don't think that using
Import-Service
and
Export-Service
is a particularly good idea. They're hard to keep in sync with your code,
they can't express more complex services and requirements, and it's not a good idea
when there's a better alternative. If there's an alternative, what is it?
MODELING BLUEPRINT SERVICES
The reason that you can't easily provision against
OSG
i services is because you don't
have anywhere to find reliable descriptions of them. Luckily, this isn't true for all
OSG
i
services. Services that are exposed using the
OSG
i Blueprint container have an easily
available, easily readable, and complete expression of all their properties—the Blue-
print itself! By parsing the Blueprint definitions in a bundle repository, generators can
quickly locate the services exported. As you saw in section 6.4.3, the service properties
for a Blueprint exposed service are also easily accessible, as illustrated here.
Listing 7.6
A Blueprint service definition
<service ref="specialOffer"
interface="fancyfoods.offers.SpecialOffer">
<service-properties>
<entry key=”shop” value=”chocolate”/>
<entry key=”open”>
<value type=”java.lang.Boolean”>true</value>
</entry>
</service-properties>
</service>
Looking again at the Blueprint, you can see that all the relevant information describ-
ing your service is available to the modeler. You can see the advertised interface and
all of the service properties. From this
XML
snippet, it's a trivial exercise to build a
Capability
describing the service.
From this example, it's clear that Blueprint offers a mechanism through which you
can model exposed services, and fortunately service requirements are as easy.
MODELING BLUEPRINT REFERENCES
In Blueprint the logical partner of the
service
element is the
reference
element.
Where
service
exposes a Blueprint bean in the Service Registry,
reference
defines a
