Previous Topic

Next Topic

Book Contents

Book Index

Subsystem

A Subsystem is collection of resources, such as bundles, or other Subsystems, administered as a whole through a Subsystem service. A subsystem may be scoped or unscoped. Scoped subsystems are isolated by implicit or explicit sharing policies. Unscoped subsystems are not isolated and, therefore, have no sharing policy. There are three standard types of subsystems.

Many use cases only require unscoped resource collections where all provided capabilities are freely exported/imported from the system.

However, in some cases, it is important to allow the exporting of provided capabilities to be scoped, so they can only be used by a subset of resources in the system. It may also be necessary to restrict the importing of required capabilities from outside the collection to ensure its internal capabilities are always preferred over capabilities outside the collection. For example, applications running on a Web application server (or in a cloud environment) may be deployed to the same server instance. The side effects of co-locating applications on the same server must be minimized, and scoping is used to ensure each application does not use the classes and services of the others.

The Subsystems specification provides a high-level declarative model for defining scoping for collections of resources, including bundles.

The OSGi framework does not provide any support for managing collections of resources. Management of collections of resources is enabled by a Subsystems implementation. When a Subsystems implementation is installed into the framework, it registers a Subsystem service. This service represents the framework as a Root Subsystem, which is a Subsystem that provides the capability to install and manage other child Subsystems, and is the parent of those Subsystems, but does not itself have a parent.