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

hoops you have to jump through to access a remote service. OSG i minimizes this prob-
lem by leveraging existing OSG i service mechanisms. In normal OSG i, bundles com-
municate via the OSG i Service Registry, which shields service clients from service
providers. It turns out that not only is this a good thing for modularity within the local
system, but that it provides excellent modularity for remote services as well!
The Remote Services Specification defines a mechanism by which a service can be
exported from the Service Registry in one OSG i framework, making it appear in
another OSG i framework. As far as the client is concerned, it can then consume both
local and remote services in exactly the same way. From the provider's perspective,
things are equally simple; they register a service into their local Service Registry, and
then wait for incoming requests. These requests may be from local bundles, or from
remote ones; the provider doesn't need to know or care.
To achieve this model, the Remote Services Specification defines two different
roles for the remoting implementation, which is usually known as the distribution
provider .

10.2.1 Exposing endpoints

When a local OSG i service is made available for remoting, it needs to be exposed as an
endpoint. This endpoint could be anything from a web service to a proprietary bit-
stream format; the important thing is that the endpoint is accessible from outside the
framework. This part of the process is relatively simple, and it's correspondingly easy to
indicate to a distribution provider that a service should be made remotely accessible. To
do this, you make use of the whiteboard pattern. Rather than looking up a remoting
provider and providing it with a remotable object, you register that remotable object as
a normal OSG i service. To indicate that your service should be made available remotely,
you add the service.exported.interfaces property to your service. The value of this
property defines the interface names that should be exposed remotely. This is a good
example of section 5.2.4 in action (see figure 10.6).

Framework

Distribution
provider

Remote
endpoint

Bundle A

service.exported.interfaces=*

Figure 10.6 A distribution provider uses the whiteboard pattern to locate remotable services and expose
them outside the OSGi framework.