Java Reference
In-Depth Information
Figure 10.11
Invoking your remote service
WARNING: WHO'S THAT URL FOR? In some cases, Distributed OSGi tries to be
too helpful in determining the default URL that it should use to register ser-
vices. Rather than using localhost, the default becomes the current external
IP address of your machine. If you find that your WSDL isn't visible on local-
host then you should try using your current IP address instead. Unfortu-
nately, you'll have to substitute this IP for localhost throughout the rest of
this example.
We do understand that many of you won't get as excited by WSDL as we do, so as a treat
why don't you try visiting http://localhost:9000/fancyfoods/offers/SpecialOffer/
getDescription? We think you'll be rather pleased by what you find. See figure 10.11.
You now have conclusive proof that CXF and Distributed OSG i have successfully
exposed your OSG i service as a publicly accessible web service. Now it's time to look at
how you can get that service into another running OSG i framework.
Discovering remote services from your superstore
We're sure you'll agree that exposing your OSG i service was extremely easy. Happily
for us, Distributed OSG i makes consuming the service back into another OSG i frame-
work just as easy.
To start with, you need to get your application from chapter 3 up and running in a
different OSG i framework. At this point, you can use the application happily, but you
won't see any offers for foreign foods (see figure 10.12).
Figure 10.12
Without your remote service
Search WWH ::

Custom Search