OSGi and the enterprise—why now? - Enterprise OSGi in Action - page 18

Service
provider

Service
consumer

Figure 1.9 A service that's provided
by one bundle and used by another
bundle. The narrow end of the triangle
points toward the service provider.

OSG i services are like META-INF services without all the messy files, or like Java Naming
and Directory Interface ( JNDI ) with more power and less ... JNDI . Although OSG i ser-
vices fill the same basic requirement as these two technologies, they have important
extra features such as dynamism, versioning, and property-based filtering. They're a
simple and powerful way for bundles to transparently share object instances without
having to expose any internal implementation—even the name of the class implement-
ing the API . By hiding the service implementation and promoting truly decoupled mod-
ules, OSG i services effectively enable a single- JVM service-oriented architecture. Services
also enable a number of other useful architectural patterns.
Figure 1.9 shows a simple OSG i service, represented by a triangle. The pointy end
faces toward the provider of the service. One way of thinking of this is that the arrow
points in the direction of invocation when a client calls the service. Another way to
think of it is that the provider of a particular service is unique, whereas there may be
many clients for it; as a result, the triangle must point at the only “special” bundle.
Alternatively, if you squint really hard the service might look to you like the spout of
an old-fashioned watering can, spreading water—or a service—out from a single
source to many potential recipients.
Providing services
Services are registered by a bundle using one or more class names that mark the API
of the service, and the service object itself. Optional properties can provide extra
information about the service and can be used by clients to filter which services get
returned when they're looking for one. Service properties aren't intended for use by
the service itself.

Properties
can be used to
refine lookups.

Dictionary<String, String> props = new Hashtable<String, String>();
props.put("check.type", "slow");
ctx.registerService(InventoryLister.class.getName(), props);
As you can see, providing a service is easy. Of course providing a service isn't useful
unless people have a way of finding and using it.
Accessing services
Services can be looked up using a simple API . Enterprise OSG i also allows services to be
accessed declaratively and injected as a dependency. We'll make use of service depen-
dency injection throughout this topic, starting in section 2.3.8. Before we get there, let's
have a peek at what a service lookup looks like without dependency injection:

String interfaceName = InventoryLister.class.getName();
ServiceReference ref = ctx.getServiceReference(interfaceName);
InventoryLister lister = (InventoryLister) ctx.getService(ref);