Java Reference
In-Depth Information
<property name="objectClass">
<array>
Service interface(s)
exposed
<value>fancyfoods.offers.SpecialOffer</value>
</array>
</property>
Your endpoint
location
<property name="endpoint.id"
value="http://localhost:9000/fancyfoods/offers/SpecialOffer"/>
<property name="service.imported.configs"
value="org.apache.cxf.ws"/>
</endpoint-description>
</endpoint-descriptions>
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
10.5
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.
