Architected Futures™

Tools and strategies ... for boiling the ocean

OSGi Architecture

Overview

Originally Eclipse was based on IBM’s Visual Age product sponsored by IBM Canada and developed by Object Technology International (later acquired by IBM).  It was released as open source as part of IBM’s effort to promote the use of Java. Starting with Eclipse v3.0, released in 2004, the OSGi Service Platform specification was selected as the runtime architecture. OSGi defines a service-oriented plug-in-based platform for application development. Efforts since that point have evolved the core platform toward a more strict conformance with the evolving OSGi specification. Equinox is the code name of the Eclipse project that provides a certified implementation of the OSGi core framework specification. Equinox implements an OSGi Release 4 core framework specification. OSGi published a Release 5 level specification on June 13, 2012.

A high-level overview of the OSGi architecture specification can be found on Wikipedia and more detailed information, including complete specifications and selected code downloads can be found at the OSGi site.

In summary, OSGi specifies a component architecture where applications are modularized and implemented in fundamental packages called bundles. Bundles are tightly coupled, dynamically loadable collections of classes, jars and configuration files that explicitly declare their external dependencies. They are implemented in the form of normal JAR components and include a detailed manifest, MANIFEST.MF, defining all of the bundle’s contents and related management information. Bundles can be installed, uninstalled, and updated at any point. They must be implemented to gracefully handle this behavior for themselves and they must be tolerant of this behavior on the part of other bundles with whom they are collaborating.

Additional portions of the OSGi framework include the following concepts:

Services The services layer connects bundles by offering a publish-find-bind model for plain old Java objects (POJOs). A service is simply an object that implements a contract and is registered with the OSGi service registry. Bundles looking to use a service discover the service in the service registry. Bundles dynamically register and unregister services they provide, and dynamically acquire and release services they consume.
Services Registry Defines the management API for services
Life-Cycle Defines the API for life-cycle management of bundles. Supports install, start, stop, update and uninstall.
Modules Defines the facility used for import and export of code
Security Defines a layer that handles security aspects by limiting bundle functionality to pre-defined capabilities

Standard Services

Standard services are defined via Java interfaces. Any bundle can implement the service and register with the service registry. Clients of the service may find it via the registry, or react to it when it appears or disappears.

OSGI System Services include:

  • Logging
  • Configuration Administration
  • Device Access
  • User Administration
  • IO Connector
  • Preferences
  • Component Runtime
  • Deployment Administration
  • Event Administration
  • Application Administration

OSGi Protocol Services include:

  • HTTP Service
  • UPnP Device Service
  • DMT Administration

OSGi Miscellaneous Services include:

  • Wire Administration
  • XML Parser
  • Measurement and State

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.