Studying services - OSGi in Action - page 118

With these techniques in mind, you'll update the ongoing paint program to use
services and see how the service layer relates to the module and lifecycle layers. We'll
conclude with a review of standard OSG i framework services and tell you more about
the compendium . As you can see, we have many useful and interesting topics to cover, so
let's get started and talk about services.

4.1 The what, why, and when of services

Before looking at OSG i services, we should first explain what we mean by a service ,
because the term can mean different things to different people depending on their
background. When you know the “what,” you also need to know why and when to use
services, so we'll get to that, too.

4.1.1 What is a service?

You may think a service is something you access across the network, like retrieving
stock quotes or searching Google. But the classical view of a service is something
much simpler: “work done for another.” This definition can easily apply to a simple
method call between two objects, because the callee is doing work for the caller.
How does a service differ from a method call? A service implies a contract between
the provider of the service and its consumers. Consumers typically aren't worried
about the exact implementation behind a service (or even who provides it) as long as
it follows the agreed contract, suggesting that services are to some extent substitut-
able. Using a service also involves a form of discovery or negotiation, implying that
each service has a set of identifying features (see figure 4.1).
If you think about it, Java interfaces provide part of a contract, and Java class link-
ing is a type of service lookup because it “discovers” methods based on signatures and
class hierarchy. Different method implementations can also be substituted by chang-
ing the JAR files on the class path. So a local method call could easily be seen as a ser-
vice, although it would be even better if you could use a high-level abstraction to find
services or if there was a more dynamic way to switch between implementations at exe-
cution time. Thankfully, OSG i helps with both by recording details of the service con-
tract, such as interface names and metadata, and by providing a registry API to publish

Figure 4.1 Services follow a contract and involve some form of discovery.