Java Reference
In-Depth Information
MODELING OSGI SERVICES
If an
OSG
i bundle uses the
OSG
i
API
to register and consume services, then there's no
metadata that describes the dependencies or capabilities offered. This causes a signifi-
cant problem for modeling. How do you model things that are only expressed in the
bytecode of a class file?
Bytecode analysis is a possibility for determining service registrations and lookups;
however, it's an extremely expensive operation. To model the bundle, you would need
to perform an in-depth analysis of
every
class contained within it. If computational
complexity were the only issue, then it probably wouldn't be a problem; however, it
isn't. Analyzing the bytecode can't always give you all the information you require.
It may seem odd that scanning the bytecode isn't able to supply all the information
you need, but in bytecode you can't always tell what the value of variables are going to
be at runtime. This means that if the interface name, the service properties, or the fil-
ter expression used when interacting with the Service Registry are able to vary at run-
time, then it can be impossible to know what they'll be. This isn't the end of your
problems, either. What if the registration of the service occurs in some other bundle
that you import a package from? Also, how can you ever know if a service is optional
or not?
Clearly, bytecode analysis is only feasible if you've found a way to solve the halting
problem, which seems rather unlikely. What would be useful would be manifest head-
ers like
Import-Package
and
Export-Package
. These would allow you to process the
services in the same way you process packages.
IMPORT-SERVICE AND EXPORT-SERVICE
Earlier versions of the
OSG
i core specification described two headers,
Import-Service
and
Export-Service
. These headers are fairly self-explanatory, and seem like the per-
fect solution to your problems. Unfortunately, there were several problems with these
headers, which means that they were deprecated and withdrawn from the core specifi-
cation. In case you're worried that this means the
OSG
i alliance makes breaking
changes to your bundles, be assured that this doesn't constitute a breaking change.
The fact that this wasn't a breaking change even provides a good example of why the
header wasn't that useful in the first place.
The problems with
Import-Service
and
Export-Service
are rather wide ranging.
First, the headers are purely informational—they have absolutely no effect on the
resolver at all. This is why it wasn't a problem for the
OSG
i alliance to remove them
from the core specification. The informational nature of these headers, and the fact
that they don't affect resolution, was a big reason for removing them. Because they
look so similar to
Import-Package
and
Export-Package
, most people mistakenly
believed that the resolver would ensure that the necessary services were available for
their bundle. Another problem with the headers was that, because they were informa-
tional, they were also optional. This made them impossible to rely upon, and there-
fore rather useless.
