 |  |  |  |  |
| | | | |
 |  |
An OSGi service is a Java class or service interface, along with a number of service properties as name/value pairs. The service properties differentiate among different service providers that provide services with the same service interface.
An OSGi service is defined semantically by its service interface and implemented as a service object. A service's functionality is defined by the interfaces it implements. Thus, different applications can implement the same service. Service interfaces allow bundles to interact by binding interfaces, not implementations. A service interface should be specified with as few implementation details as possible.
In the OSGi Framework, the Service layer provides communication among modules and their contained components using the publish, find, and bind service model. The Service layer contains a service registry where services are registered with the Framework to be used by other applications and clients can look up available services. A bundle can register an implementation of a service with the service registry. Other bundles can look up and use the service. Lookup is performed via Java interface and service properties.
Bundles are built around a set of cooperating services available from a shared service registry. A service is a normal Java object that is registered under one or more Java interfaces with the service registry. The service object is owned by, and runs within, a bundle. This bundle must register the service object with the Framework service registry so that the service’s functionality is available to other bundles under the control of the Framework.
Service interfaces are implemented by objects created by the bundle. Bundles can register services, search for them, or receive notifications when their registration state changes.
Each bundle can register any number of services in the service registry using the fully qualified name of its interface and its properties. The name and properties are then used when the registry is queried using LDAP query language. Bundles can select an available implementation at runtime from the Framework service registry using queries formulated with LDAP syntax.
A bundle is responsible for runtime service dependency management activities including publication, discovery, and binding, as well as adapting to changes resulting from dynamic availability (arrival or departure) of services that are bound to the bundle. In OSGi, both service providers and service requestors are part of a bundle.
Service providers publish their services in a service registry
Service requestors use the service registry to find services and bind to service providers
The OSGi Framework maps services to their underlying service objects, and provides a simple but powerful query mechanism that enables a bundle to request the services it needs.
The OSGi Framework provides an event notification mechanism so service requesters can receive notification events signalling changes in the service registry. These changes include the publication or retrieval of a particular service and services that are registered, modified, or unregistered.
In OSGi a service is defined using a Java interface. Services in OSGi are Java objects, invoked using local method invocations.
OSGi services allow bundles to share Java objects. The OSGi bundle abstraction allows modules to share Java classes. This is a static form of reuse. The shared classes must be available when the dependent bundle is started.
When a bundle wants to use a service, it looks up the service and invokes the Java object as a normal Java call. Therefore, invocations on services are synchronous and occur in the same thread. You can use callbacks for more asynchronous processing. Parameters are passed as Java object references. No marshalling or intermediary canonical formats are required as with XML. OSGi also provides mechanisms to deal with services being unavailable.
The OSGi Framework provides optional services to manage the operation of the Framework:
Permission Admin service —
Enables the OSGi Framework's Management Agent to administer the permissions
of a specific bundle and provide defaults for all bundles. A bundle can have
a single set of permissions that are used to verify that a bundle is
authorized to execute privileged code. For example,
FilePermission defines which files can be used and how.
Conditional Permission Admin service — Extends the Permission Admin service with permissions that can apply when certain conditions are true or false at the time the permission is checked. Permissions are activated immediately once they are set. For more information, see Managing Permissions.
Package Admin service — Allows a Management Agent to define the policy for managing package sharing by examining the status of the shared packages. It also allows the Management Agent to refresh packages and stop and restart bundles as required. The service lets the Management Agent make decisions regarding any shared packages when an exporting bundle is uninstalled or updated. The service also provides methods to refresh any exported packages that were removed or updated since the last refresh, and to explicitly resolve specific bundles. This service can also trace dependencies between bundles at runtime so you can see what bundles might be affected by upgrading.
Start Level service — Enables a Management Agent to control the relative starting and stopping order of bundles. The service assigns each bundle a start level. The Management Agent can modify the start levels of bundles and set the active start level of the Framework, which starts and stops the appropriate bundles. Only bundles that have a start level less than or equal to this active start level must be active.
URL Handlers service — Dynamically extends the Java runtime with URL schemes and content handlers enabling any component to provide additional URL handlers.
The services are described in detail in separate chapters in the OSGi Service Platform Release 4 specification available from the release 4 download page on the OSGi Alliance web site.
In addition to the OSGi Framework services, the OSGi Alliance defines a set of optional, standardized compendium services. The OSGi compendium services provide APIs for tasks like logging and preferences. These services are described in the OSGi Service Platform, Service Compendium available from the specifications drafts page on the OSGi Alliance site.
A JAR file containing compendium services is located in your install directory in:
\system\org\apache\felix\org.osgi.compendium\
The Configuration Admin compendium service is like a central hub that persists configuration information and distributes it to interested parties. The Configuration Admin service specifies the configuration information for deployed bundles and ensures that the bundles receive that data when they are active. The configuration data for a bundle is a list of name-value pairs. See FUSE ESB Kernel.
| |  | |
 |
