Figure 10.7 A distribution provider can also create OSGi services within an OSGi framework that delegate
to remote endpoints.
Both registering and consuming remotable services is easy, mostly because of the ser-
vice discovery part of the distribution provider. This part of the distribution provider
is responsible for detecting when new remote services are available, and they're for
registering proxy services in the local framework. These proxy services mirror the
backing services in the remote framework, including any changes in their service
properties. The proxy services are also unregistered if the remote service becomes
unavailable. Imported services (ones that proxy a service in a remote framework) also
have a number of other properties registered by the distribution provider. Impor-
tantly, if the service.imported property is set to any value , then this service is a proxy
to a remote service in another framework (see figure 10.7).
One further detail to note is that distribution providers are only required to sup-
port a limited set of parameter types when making remote invocations. These are
primitive types, wrapper types for primitives, and Strings. Distribution providers must
also cope with arrays or collections of these types.
Now that you understand the basics of the Remote Services Specification, let's try
extending your superstore with a remote department.
Writing a remotable service
In chapter 3, you built an extensible facility for special offers. This is an excellent oppor-
tunity for you to add a remote special offer service. Writing a remote department for
your superstore will be simple. It'll be the foreign foods department, and you'll base it
heavily on the departments you've written before. Also, thanks to OSG i's modular, reus-
able bundles you can take the fancyfoods.api , fancyfoods.persistence , and fancy-
foods.datasource bundles from chapter 3 without making any changes at all. Figure
10.8 shows the architecture of the distributed Fancy Foods system.
Search WWH ::