Java Reference
In-Depth Information
http://localhost:8080/stockwatcher/stockPrices/, and enter the stock name
foo
. You
should see results appear in the browser and in the output of the first console, as follows:
Retrieved {FOO=4.736842484258008}
Retrieved {FOO=48.88924250369791}
Retrieved {FOO=22.847587831790904}
This output shows that the method invocation of the local
StockProvider
service is
being sent across the wire from the stock-watcher
JVM
using
SOAP
to the stock-provider
JVM
. Very cool!
Dealing with failure
One thing that should be obvious to experienced developers of distributed software
is that remote services are unreliable. In RMI, for example, this unreliability is dealt
with by using
java.rmi.RemoteException
, which is a checked exception to inform
the client when things go wrong during attempts to communicate with a remote ser-
vice. In OSGi, the equivalent exception is
osgi.framework.ServiceException
, but
in this case it's an unchecked exception. Regardless, you should expect these types
of exceptions to occur when dealing with a remote service.
As you can see, it's fairly straightforward to configure a distribution provider to import
a remote service for use locally. In the example, the client isn't particularly picky
about which
StockProvider
service it uses: it takes whichever one is available in the
service registry. The Remote Services specification allows the consumer to be more
selective; we'll conclude this section by looking into how it does so.
MATCHMAKING SERVICES
Earlier, we covered how the service provider uses intents and configuration to have
control over how its service is exposed remotely. In a symmetric fashion, clients often
need to use services with specific characteristics. For example, a medical insurance
web application may require encrypted communications to ensure patient confidenti-
ality, or a financial trading application may require a certain protocol to communicate
between services for performance or regulatory reasons. Using the
OSG
i service regis-
try's query mechanism, clients can select services using filters over the intents and
configurations specified on published services.
Let's consider the simplest case of differentiating between local and remote ser vices.
In this case, the Remote Services specification requires distribution providers to auto-
matically add a
service.imported
service property to imported remote services. If you
explicitly want to bind to only a remote service, you can use a filter like the following:
ServiceReference ref =
context.getServiceReferences(
MyService.class.getName(),"(service.imported=*)")
Alternatively, if you explicitly want to bind to only a local service, you use a filter like
the following:
