Thursday, February 12, 2009

JBossOSGi - Technology Overview

The Open Services Gateway Initiative (OSGi), specifications define a standardized, component-oriented, computing environment for networked services that is the foundation of an enhanced service-oriented architecture.

The OSGi specification defines two things:
  • A set of services that an OSGi container must implement
  • A contract between the container and your application
Developing on the OSGi platform means first building your application using OSGi APIs, then deploying it in an OSGi container.

What does OSGi offer to Java developers?

OSGi modules provide classloader semantics to partially expose code that can then be consumed by other modules. The implementation details of a module, although scoped public by the Java programming language, remain private to the module. On top of that you can install multiple versions of the same code and resolve dependencies by version and other criteria. OSGi also offers advanced security and lifecycle, which I'll explain in more detail further down.

What kind of applications benefit from OSGi?


Any application that is designed in a modular fashion where it is necessary to start, stop, update individual modules with minimal impact on other modules. Modules can define their own transitive dependencies without the need to resolve these dependencies at the container level. The OSGi platform builds an exellent foundation for the next generation JBoss ESB for example.

Should Java EE developers adopt the OSGi programming model?

Probably not. The OSGi runtime may be used internally by Java EE container providers to achieve the desired isolation and configuration flexibility that the container whishes to provide. At the application programming level, the Java EE model will continue to exist in its own right, wheras the OSGi model may provide the more suitable runtime environment for applications that require the modular isolation, security and lifecycle management that OSGi offers.

OSGi Framework Overview

The functionality of the Framework is divided in the following layers:
  • Security Layer
  • Module Layer
  • Life Cycle Layer
  • Service Layer
  • Actual Services


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 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 can carry 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



Appart 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

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 Famework events
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.



The OSGi Service Compendium

The OSGi Service Compendium specifies a number of services that may be available in an OSGi runtime environment. Although the OSGi Framework specification is useful in itself already, it only defines the OSGi core infrastructure. The services defined in the compendium specification define the scope and functionality of some common services that bundle developers might want to use. Here is a quick summary:

The Log Service provides a general purpose message logger for the OSGi Service Platform. It consists of two services, one for logging information and another for retrieving current or previously recorded log information.

The Http Service supports two standard techniques for registering servlets and resources to develop communication and user interface solutions for standard technologies such as HTTP, HTML, XML, etc.

The Device Access specification supports the coordination of automatic detection and attachment of existing devices on an OSGi Service Platform, facilitates hot-plugging and -unplugging of new devices, and downloads and installs device drivers on demand.

The Configuration Admin service allows an Operator to set the configuration information of deployed bundles.



The Metatype Service specification defines interfaces that allow bundle developers to describe attribute types in a computer readable form using so-called metadata.

The Preferences Service allows storage of data that is specific to a particular user.

Bundles can use the User Admin Service to authenticate an initiator and represent this authentication as an Authorization object. Bundles that execute actions on behalf of this user can use the Authorization object to verify if that user is authorized.

The Wire Admin Service is an administrative service that is used to control a wiring topology in the OSGi Service Platform. It is intended to be used by user interfaces or management programs that control the wiring of services in an OSGi Service Platform.

The IO Connector Service specification adopts the Java 2 Micro Edition (J2ME) javax.microedition.io packages as a basic communications infrastructure.

The UPnP Device Service specifies how OSGi bundles can be developed that interoperate with UPnP (Universal Plug and Play) devices and UPnP control points.

The Declarative Services specification addresses some of the complications that arise when the OSGi service model is used for larger systems and wider deployments, such as: Startup Time, Memory Footprint, Complexity. The service component model uses a declarative model for publishing, finding and binding to OSGi services.

The Event Admin Service provides an inter-bundle communication mechanism. It is based on a event publish and subscribe model, popular in many message based systems.

The Deployment Admin Service specification, standardizes the access to some of the responsibilities of the management agent: that is, the lifecycle management of interlinked resources on an OSGi Service Platform.

The Auto Configuration Specification is to allow the configuration of bundles. These bundles can be embedded in Deployment Packages or bundles that are already present on the OSGi Service Platform.

The Application Admin Service is intended to simplify the management of an environment with many different types of applications that are simultaneously available.

The DMT Admin Service specification defines an API for managing a device using concepts from the OMA DM specifications.

The Monitor Admin Service specification outlines how a bundle can publish Status Variables and how administrative bundles can discover Status Variables as well as read and reset their values.

The Foreign Application Access specification is to enable foreign application models like MIDP, Xlets, Applets, other Java application models to participate in the OSGi service oriented architecture.

The Service Tracker specification defines a utility class, ServiceTracker, that makes tracking the registration, modification, and unregistration of services much easier.

The XML Parser Service specification addresses how the classes defined in JAXP can be used in an OSGi Service Platform.

The Position Specification provides bundle developers with a consistent way of handling geographic positions in OSGi applications.

The Measurement and State Specification provides a consistent way of handling a diverse range of measurements for bundle developers.

This Execution Environment Specification defines different execution environments for OSGi Server Platform Servers.

What is there to come?

The intention of this initial blog was to provide folks that have not yet come in contact with this exciting technology a brief overview of what OSGi has to offer. I barely scratched the surface of what this all entails - may it still be useful.

In my next blog I'm going to write about the JBossOSGi Service Provider Interface (SPI) and how we integrate Apache Felix to provide an OSGi runtime based on the Microcontainer. You will learn about JBossOSGi Deployers and how to use the JBossOSGi HttpService to setup an Http endpoint. As prove of concept we run the Apache Felix Web Console on JBossWeb and use it to manage the JBossOSGi Runtime - stay tuned.

References

[1] Hello, OSGi, Part 1: Bundles for beginners
http://www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html
[2] OSGi Business WhitePaper
http://www.osgi.org/wiki/uploads/Links/OSGiBusinessBenefitsWhitepaper.pdf
[3] OSGi Technical WhitePaper
http://www.osgi.org/wiki/uploads/Links/OSGiTechnicalWhitePaper.pdf