Hooking up remote systems with distributed OSGi - Enterprise OSGi in Action - page 254

Figure 10.9 The
local view of your
remote service

Your foreign foods department can't do much at the moment; it's not even available
remotely. For that you need a remote services implementation.

10.4 Adding in your remote service using Apache CXF

Apache CXF hosts the Distributed OSG i project, which is the reference implementation
of the Remote Services Specification. (Other implementations, such as Eclipse ECF and
Paremus Nimble, are also available.) Distributed OSG i makes use of CXF 's web services
runtime to expose OSG i services as web services. Distributed OSG i then uses CXF 's web
service client code to implement local OSG i service proxies to remote web services. By
gluing these two pieces together, you get a complete remote services implementation.
Distributed OSG i is easy to use and will allow you to quickly and simply expose your
foreign foods special offers to the outside world.

10.4.1 Making your service available

Distributed OSG i is available in two forms: as a set of OSG i bundles, or as a single bun-
dle that packages its dependencies (sometimes known as an uber bundle ). Both forms
are reasonably common ways to release OSG i services; the former gives good modular-
ity and fine control, whereas the latter is useful for getting up and running quickly.
Because you want to start selling your foreign food as soon as possible, you'll be using
the single bundle distribution of Distributed OSG i 1.2, which is available at http://
cxf.apache.org/dosgi-releases.html .
You need to get the Distributed OSG i implementation into your framework, which
can easily be achieved by dropping it into the load directory of your running frame-
work. Adding this bundle will cause a huge flurry of activity, but importantly it will cre-
ate a web service for any service that declares a service.exported.interface !
CONFIGURING YOUR DISTRIBUTION PROVIDER
It isn't immediately clear where Distributed OSG i has registered your web service, and
it also isn't clear how you could get the service to be registered somewhere else. At this
point, it's worth knowing that the Remote Services Specification defines a configura-
tion property, service.exported.configs . This property can be used to define alter-
natives (different places where the same service should be registered) and synonyms
(different configurations for the same service endpoint). If more than one configura-
tion is required, then the service property can be an array of configurations.