![](https://csdnimg.cn/release/download_crawler_static/8827283/bg10.jpg)
Application and Provisioning Support Introduction
Page 4 OSGi Enterprise Release 5
1.1.9 Miscellaneous Supporting Services
Services providing solutions to common infrastructure requirements include:
• Log Service Specification – Provides a general purpose message logger for the OSGi framework. See
101 Log Service Specification.
• XML Parser Service Specification – Addresses how the classes defined in JAXP can be used in an OSGi
framework. See 702 XML Parser Service Specification.
• Service Loader Mediator Specification – Addresses common problems of bundles that rely on the JRE
provided Service Loader API to load custom Service Provider Implementations. This specification
describes how to use the service registry for lookup of Service Providers as well as a solution for
existing code to continue functioning using Service Loader API in a OSGi environment. See 133
Service Loader Mediator Specification.
• Coordinator Specification – The Coordinator service provides a mechanism for multiple parties to
collaborate on a common task without a priori knowledge of who will collaborate in that task.
The service provides a rendezvous for an initiator to create a Coordination where collaborators
can decide to participate. When the Coordination is ended, all participants are informed. See 130
Coordinator Service Specification.
1.2 Application and Provisioning Support
The support for applications in OSGi environments has long been missing. The term ‘application’
may mean different things to different people, therefore, rather than defining what an application is,
the OSGi specification provides a set of enabling services and specifications to aid in the definition,
composition, deployment, and governance of a group of bundles and resources in an OSGi environ-
ment. The specifications are essential building blocks and provide from low level resolution to
higher level composition abstractions that a management agent can use to build the necessary tools
for managing OSGi applications.
• Resolver Hook Service Specification - An enabling technology defined by the Core Specification for
OSGi frameworks to support isolation of bundles.
• Resolver Specification - A service that can be the base for provisioning, deployment, build, and diag-
nostic tooling. Based on the generic Requirement/Capability model from the Core Specification a
management agent can use the Resolver service to compute the set of necessary resources needed
to satisfy the given set of requirements. These requirements could represent the dependencies of a
core set of bundles that need to be deployed. While the framework already hosts a Resolver for
Bundle wiring, this specification makes a generic Resolver available as a service to resolve depen-
dencies on resources beyond Bundle wiring. See 131 Resolver Service Specification.
• Repository Specification - The Repository specification provides a standard API to access (possibly
remote) repositories. Resources can be obtained from the repository by specifying declarative
requirements, which might include for example ‘provide all resources that export a given
package’ or ‘provide the bundle with the given symbolic name and version’, but can also be used
with any other generic capabilities. While the Repository API can be used on its own, in con-
junction with the Resolver Specification it provides the capability to manage retrieval of external
resources during the resolution process. Typically one or multiple repositories provide the
metadata for the Resolver service to draw the resolution from. A management agent can then use
the repositories to apply the result of the resolution. See 132 Repository Service Specification.
• Subsystems Specification - The core framework defines the life cycle of bundles and their relation-
ships, but it is missing the ability to define a common life cycle and scoping rules for a set of
bundles that are conceptually tied together. The Subsystems Specification provides the ability not
only to group multiple bundles into a single manageable entity, but furthermore include arbi-
trary resources in this grouping. This allows for complete isolation as well as various sharing
models of code, services, and resources through a management agent. See 134 Subsystem Service
Specification.