Java Reference
In-Depth Information
<property name="objectClass">
Service interface(s)
Your endpoint
<property name=""
<property name="service.imported.configs"
As you can see in listing 10.5, you provide the URL for your endpoint, as well as its
interface type and some information about how the service was exported, in this case
as a CXF -generated web service. This is rather brittle, unless you have a known proxy
server that can get the routing right for you. For now a fixed URL is fine. If you build
your manifest and XML configuration into a bundle and drop it into the load direc-
tory of your client system, then something rather magical happens when you refresh
the front page of your superstore.
As you can see in figure 10.16, your special offers now include some foreign food
from your remote system! Note that you didn't make any changes to your API or to the
client application, and that you wrote a total of two manifests, two classes, and two
XML files. This is how easy life can be when you have a modular OSG i application. We
hope it's as exciting for you as it is for us!
Type of endpoint
to import
Figure 10.16
Your remote-enabled superstore
Using your remote application
You could stop adapting your application here, now that you know how to expose and
consume a remote OSG i service in a transparent way using only standard configura-
tion. On the other hand, there was more to your application than the special offers on
the front page. What happens if you try to buy some of the foreign food that you've
added? Clicking on the link to your special offer yields the page shown in figure 10.17.
The page in figure 10.17 is promising; everything looks about right, but what hap-
pens if you attempt to complete a purchase? See figure 10.18.
Search WWH ::

Custom Search