Java Reference
In-Depth Information
Let's have a look at how the remote services behave in your SCA runtime. Build the bundle and drop it into the load directory. You
should see the bundle appear, but more interestingly, you should also see some new
services appear. List the services that implement the SpecialOffer as follows:
osgi> services (objectClass=fancyfoods.offers.SpecialOffer)
As well as the familiar cheese and chocolate offers, there's a new offer, with lots of extra
SCA -specific service properties. You may expect the bundle that registers the service
would be the bundle. But it's the bundle that consumes
which registers its remote representation. If no bundles consume the remote service, it
won't even be registered. (And if you stop the bundle,
the SpecialOffer service will be unregistered.)
At this point, you may be slightly suspicious. You haven't written the SCA foreign
food service implementation, much less deployed and started it. How can a service be
available when there's no backend?
If you try to access the Fancy Foods front page, you'll discover that the backing
remote service is definitely missing, which makes a mess (see figure 10.23).
The SCA runtime registers services based on what's in the bundle metadata, but it
doesn't require the backing services to be available until they're used. This may seem
error prone, and in a sense it is—but it's merely reflecting the fact that remote invoca-
tions are naturally subject to service interruptions. Networks are inherently unreliable,
and remote services may come and go, so even if the remote service is available at the
time of registration, it might have vanished by the time it's used. This volatility is some-
thing to be aware of when using services that could be remote; more error handling
Figure 10.23 If the remote implementation of a remote service is missing, the service will still be avail-
able, but using it will cause errors.
Search WWH ::

Custom Search