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?
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"
<entry key=”shop” value=”chocolate”/>
<entry key=”open”>
<value type=”java.lang.Boolean”>true</value>
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.
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
Search WWH ::

Custom Search