Java Reference
In-Depth Information
Table 4.1
Example characteristics of real-world services
Characteristic
Why may you be interested?
Supported locales
A price-checking service may only be available for certain currencies.
Tr a n s a c t i o n c o s t
You may want to use the cheapest ser vice, ev en if it takes longer.
Throughput
You may want to use the fastest ser v ice, regardless of cost.
Security
You may only want to use ser v ices that are digitally signed by cer tain
providers.
Persistence
characteristics
You may only want to use a ser vice that guarantees to store your data
in such a way that it won't be lost if the JVM restarts.
As you can see, metadata can capture fine-grained information about your application
in a structured way. This is helpful when you're assembling, supporting, and maintain-
ing an application. Recording metadata alongside a service interface also means you
can be more exact about what you need. The service framework can use this metadata
to filter out services you don't want, without having to load and access the service itself.
But why would you want to do this? Why not just call a method on the service to ask
if it does what you need?
SUPPORT FOR MULTIPLE COMPETING IMPLEMENTATIONS
A single Java interface can have many implementations; one may be fast but use a lot
of memory, another may be slow but conserve memory. How do you know which one
to use when they both implement the same interface? You could add a query method
to the interface that tells you more about the underlying implementation, but that
would lead to bloat and reduce maintainability. What would happen when you added
another implementation that couldn't be characterized using the existing method?
Using a query method also means you have to find and call each service implementa-
tion before you know whether you want to use it, which isn't efficient—especially
when you may have hundreds of potential implementations that could be loaded at
execution time.
Because service frameworks help
you record metadata alongside services,
they can also help you query and filter
on this metadata when discovering ser-
vices. This is different from classic
dependency injection frameworks,
which look up implementations based
solely on the interfaces used at a given
dependency point. Figure 4.5 shows
how services can help you get exactly
what you want.
We hope that, by now, you agree
that services are a good thing—but as
Leg
Leg
Leg
Leg
Metadata
color:silver
side:right
Metadata
color:gold
side:left
Dependency injection
Service discovery
Figure 4.5
Simple dependency injection vs. service
discovery
