The functionality of the Framework is divided in the following layers:
Security Layer (optional)
Module Layer
Life Cycle Layer
Service Layer
Actual Services
OSGi Security Layer
The OSGi Security Layer is an optional layer that underlies the OSGi Service Platform. The layer is based on the Java 2 security architecture. It provides the infrastructure to deploy and manage applications that must run in fine grained controlled environments.
The OSGi Service Platform can authenticate code in the following ways:
By location
By signer
For example, an Operator can grant the ACME company the right to use networking on their devices. The ACME company can then use networking in every bundle they digitally sign and deploy on the Operator’s device. Also, a specific bundle can be granted permission to only manage the life cycle of bundles that are signed by the ACME company.
The current version of JBoss OSGi does not provide this optional layer. If you would like to see this implemented, let us know on the forums: http://community.jboss.org/en/jbossosgi .
OSGi Module Layer
The OSGi Module Layer provides a generic and standardized solution for Java modularization. The Framework defines a unit of modularization, called a bundle. A bundle is comprised of Java classes and other resources, which together can provide functions to end users. Bundles can share Java packages among an exporter bundle and an importer bundle in a well-defined way.
Once a Bundle is started, its functionality is provided and services are exposed to other bundles installed in the OSGi Service Platform. A bundle carries descriptive information about itself in the manifest file that is contained in its JAR file. Here are a few important Manifest Headers defined by the OSGi Framework:
Bundle-Activator - class used to start, stop the bundle
Bundle-SymbolicName - identifies the bundle
Bundle-Version - specifies the version of the bundle
Export-Package - declaration of exported packages
Import-Package - declaration of imported packages
The notion of OSGi Version Range describes a range of versions using a mathematical interval notation. For example
Import-Package: com.acme.foo;version="[1.23, 2)", com.acme.bar;version="[4.0, 5.0)"
With the OSGi Class Loading Architecture many bundles can share a single virtual machine (VM). Within this VM, bundles can hide packages and classes from other bundles, as well as share packages with other bundles.
For example, the following import and export definition resolve correctly because the version range in the import definition matches the version in the export definition:
A: Import-Package: p; version="[1,2)" B: Export-Package: p; version=1.5.1
Apart from bundle versions, OSGi Attribute Matching is a generic mechanism to allow the importer and exporter to influence the matching process in a declarative way. For example, the following statements will match.
A: Import-Package: com.acme.foo;company=ACME B: Export-Package: com.acme.foo;company=ACME; security=false
An exporter can limit the visibility of the classes in a package with the include and exclude directives on the export definition.
Export-Package: com.acme.foo; include:="Qux*,BarImpl"; exclude:=QuxImpl
OSGi Life Cycle Layer
The Life Cycle Layer provides an API to control the security and life cycle operations of bundles.
A bundle can be in one of the following states:
A bundle is activated by calling its Bundle Activator object, if one exists. The BundleActivator interface defines methods that the Framework invokes when it starts and stops the bundle.
A Bundle Context object represents the execution context of a single bundle within the OSGi Service Platform, and acts as a proxy to the underlying Framework. A Bundle Context object is created by the Framework when a bundle is started. The bundle can use this private BundleContext object for the following purposes:
Installing new bundles into the OSGi environment
Interrogating other bundles installed in the OSGi environment
Obtaining a persistent storage area
Retrieving service objects of registered services
Registering services in the Framework service
Subscribing or unsubscribing to Framework events
OSGi Service Layer
The OSGi Service Layer defines a dynamic collaborative model that is highly integrated with the Life Cycle Layer. The service model is a publish, find and bind model. A service is a normal Java object that is registered under one or more Java interfaces with the service registry. OSGi services are dynamic, they can come and go at any time. OSGi service consumers, when written correctly, can deal with this dynamicity. This means that OSGi services provide the capability to create a highly adaptive application which, when written using services, can even be updated at runtime without taking the service consumers down.
The OSGi Declarative Services and OSGi Blueprint specifications significantly simplify the use of OSGi Services which means that a consumer gets the benefits of a dynamic services model for very little effort.