Java Reference
In-Depth Information
Any bundles that depended on the now-absent uninstalled bundle will be stopped and
re-resolved. This may mean that they move all the way back to the INSTALLED state.
Stopping and uninstalling aren't the only actions that can impact dependent bun-
dles. OSG i bundles can be dynamically updated, and an update may remove previously
exported packages or introduce new package requirements. As with uninstalled bun-
dles, the removed exports will remain available to existing users (from the old pre-
update version of the bundle) until the framework is restarted or refreshed.
Services are an extremely important part
of OSG i. Services allow bundles to share
object instances in a loosely coupled way.
Figure A.7 shows a simple OSG i ser-
vice, represented by a triangle. The
pointy end faces the provider, not the
consumer. The reason is that the service
can only have one provider, but it can
have lots of consumers.
Figure A.7 A service that is provided by one
bundle and used by another bundle. The triangle
points toward the service provider.
The Service Registry
Management and discovery of services is handled by a shared Service Registry. Ser-
vices are registered and retrieved using interface names and optional query parame-
ters. (We'll come to service filters in section A.5.3.)
Services are registered on the bundle context. (If you're using Blueprint, this hap-
pens under the covers for you.) Services can only be provided by bundles that are
STARTED . When a service is registered by a bundle, it provides one or more class
names that mark the API of the service, and the service object itself. Optional proper-
ties can provide extra information about the service, and can be used to filter what
services get returned when services are looked up. Service properties aren't intended
for use by the service itself.
If Blueprint or Declarative Services aren't used, registration of a service can be
done in a couple of lines of code as follows:
Hashtable<String, String> props = new Hashtable<String, String>();
props.put("check.type", "slow");
ctx.registerService(SpecialOffer.class.getName(), props);
Properties used
to refine lookups
By using String interface names and simple property types, the OSG i Service Registry
allows OSG i bundles to avoid worrying about their class spaces. If two versions of a ser-
vice interface exist, then it's only possible to use an implementation that you share a
view of the interface with. If you were to try to use a service that was in a different class
space from your bundle, then you would generate a ClassCastException . This may
seem odd, but in Java, a class is identified not only by its name, but by the classloader
that loaded it.
Search WWH ::

Custom Search