Web applications and web services - OSGi in Action - page 502

ServiceReference ref =
context.getServiceReferences(
MyService.class.getName(),"(!(service.imported=*))")
Now, let's consider the more complex case of matching remote-service qualities. You
saw earlier that a service provider can specify various intents ( propagatesTransac-
tion , authentication , and so on) when publishing its service. We also mentioned
that a distribution provider can augment this set. The Remote Services specification
requires distribution providers to automatically add a service.intents service prop-
erty to imported remote services, which contains the union of the service provider
and distribution provider intents. Therefore, if you want a service that propagates
transactions and uses encryption, you can use a filter like the following:

ServiceReference ref =
context.getServiceReferences(
MyService.class.getName(),
"(&(service.intents=propagatesTransaction)
(service.intents=confidentiality))")

Matching qualified intents and configurations
One slightly thorny area surrounds the matching of qualified intents where, for ex-
ample, the client requires service.intents=confidentiality , but a service pro-
vides service.intents=confidentiality.message . These two intents should
match because the client doesn't care how the confidentiality is achieved, but a
pure LDAP filter match would fail. To work around such issues, the Remote Services
specification requires distribution providers to expand all implied qualified intents
on services so LDAP queries function intuitively. For example, service.
intents=confidentiality.message becomes service.intents="confidenti-
ality,confidentiality.message" .

We've looked at how the Remote Services distribution provider makes it easy to pub-
lish and consume remote services within an OSG i-based environment. What if you're
coming at this from the other side? What if you're a distributed software developer
and want to import/export services from/to the OSG i service registry using your own
distribution technology of choice? In that case, you'll need to implement your own
distribution provider. We'll briefly look into doing this next.

15.2.3 Distributing services

In this section, we'll lead you through a short example showing how you can imple-
ment a trivial distribution-provider framework. The goal isn't to create something par-
ticularly useful, but to show the underlying mechanics at play.
For the purposes of this example, you'll create a simple RemoteRegistry interface
to abstract away the details of dealing with remote services. You'll first see how you can
export local OSG i services into your remote registry; then you'll see how to import
remote services into the local OSG i service registry. Figure 15.10 provides a view of the
classes involved in this example.