About / OSGi Technology
Search:

OSGi Technology

THE PROBLEM

Software complexity is increasing at an alarming rate. Today, a large part of this complexity is caused by shortened product cycles, requirements for drastically increased functionality, and an increasing number of variations of the same product (e.g. different hardware and operating systems). These trends have caused software costs to become a larger percentage of almost any manufacturer's development cost.

Today, software development largely consists of adapting existing functionality to perform in a new environment. In the last 20 years, a large number of standard building blocks have become available and they are heavily used in today's products; a prime example is the success of open software. However, the use of these libraries is not without problems. Integrating many different libraries can be daunting because many libraries have become complex and require their own libraries to function -- even if that functionality is never needed for the product.

This trend requires monolithic software products to undergo a heavy testing cycle. Add unsynchronized evolution of the different libraries and it becomes clearer why software development is so costly today.

A key issue is that today's software environments focus on writing new software, instead of integrating existing software into new systems. In reality, integrating existing code has become a large part of the work of software developers. Therefore, there is a need for tools that standardize the integration aspects of software so that reusing existing components becomes reliable, robust and cheap.

THE SOLUTION

OSGi technology is the dynamic module system for Java™. The OSGi Service Platform provides functionality to Java that makes Java the premier environment for software integration and thus for development. Java provides the portability that is required to support products on many different platforms. The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed.

The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring restarts. To minimize the coupling, as well as make these couplings managed, the OSGi technology provides a service-oriented architecture that enables these components to dynamically discover each other for collaboration. The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more. Plug-compatible implementations of these components can be obtained from different vendors with different optimizations and costs. However, service interfaces can also be developed on a proprietary basis.

OSGi technology adopters benefit from improved time-to-market and reduced development costs because OSGi technology provides for the integration of pre-built and pre-tested component subsystems. The technology also reduces maintenance costs and enables unique new aftermarket opportunities because components can be dynamically delivered to devices in the field.

THE FRAMEWORK

The core component of the OSGi Specifications is the OSGi Framework. The Framework provides a standardized environment to applications (called bundles). The Framework is divided in a number of layers.

  • L0: Execution Environment
  • L1: Modules
  • L2: Life Cycle Management
  • L3: Service Registry A ubiquitous security system is deeply intertwined with all the layers.

The L0 Execution environment is the specification of the Java environment. Java 2 Configurations and Profiles, like J2SE, CDC, CLDC, MIDP etc. are all valid execution environments. The OSGi platform has also standardized an execution environment based on Foundation Profile and a smaller variation that specifies the minimum requirements on an execution environment to be useful for OSGi bundles.

The L1 Modules layer defines the class loading policies. The OSGi Framework is a powerful and rigidly specified class-loading model. It is based on top of Java but adds modularization. In Java, there is normally a single classpath that contains all the classes and resources. The OSGi Modules layer adds private classes for a module as well as controlled linking between modules. The module layer is fully integrated with the security architecture, enabling the option to deploy closed systems, walled gardens, or completely user managed systems at the discretion of the manufacturer.

The L2 Life Cycle layer adds bundles that can be dynamically installed, started, stopped, updated and uninstalled. Bundles rely on the module layer for class loading but add an API to manage the modules in run time. The lifecycle layer introduces dynamics that are normally not part of an application. Extensive dependency mechanisms are used to assure the correct operation of the environment. Life cycle operations are fully protected with the security architecture, making it virtually impossible to be attacked by viruses.

The L3 layer adds a Service Registry. The service registry provides a cooperation model for bundles that takes the dynamics into account. Bundles can cooperate via traditional class sharing but class sharing is not very compatible with dynamically installing and uninstalling code. The service registry provides a comprehensive model to share objects between bundles. A number of events are defined to handle the coming and going of services. Services are just Java objects that can represent anything. Many services are server-like objects, like an HTTP server, while other services represent an object in the real world, for example a Bluetooth phone that is nearby. The service model is fully security instrumented. The service security model provides an elegant way to secure the communication between bundles passes.

UBIQUITOUS SECURITY

Security is based on Java and the Java 2 security model. The language by design limits many possible constructs. For example, buffer overflows used in viruses are impossible. Access modifiers in the language restrict the visibility of the code to other programmers. The OSGi platform extends this model by allowing private classes, a mechanism that is not available in a standard way in Java. The Java 2 security model provides a comprehensive model to check access by code to resources. The OSGi platform adds full dynamic management of the permissions, simplifying the life of operators and system administrators.

STANDARD SERVICES

On top of the Framework, the OSGi Alliance has specified many services. Services are specified by a Java interface. Bundles can implement this interface and register the service with the Service Registry. Clients of the service can find it in the registry, or react to it when it appears or disappears.

This is similar to the service-oriented architecture made popular with web services. The key difference between web services and OSGi services is that web services always require some transport layer, which makes it thousands times slower than OSGi services that use direct method invocations. Also, OSGi components can directly react on the appearance and disappearance of services.

The following sections give a short overview of the OSGi Release 4 services. More information can be found in the OSGi Service Platform Release 4 book or PDF download. Note that each service is defined abstractly and is independently implemented by different vendors.

FRAMEWORK SERVICES

The OSGi Framework provides a Permission Admin Service, a Package Admin Service and a Start Level Service. These services are (an optional) part and direct the operation of the Framework. Framework services are the following:

  • (Conditional) Permission Admin – The permissions of current or future bundles can be manipulated through this service. Permissions are activated immediately once they are set.
  • Package Admin – Bundles share packages with classes and resources. The update of bundles might require the system to re-calculate the dependencies. This Package Admin service provides information about the actual package sharing state of the system and can also refresh shared packages. I.e. break the dependencies and recalculate the dependencies.
  • Start Level – Start Levels are a set of bundles that should run together or should be initialized before others are started. The Start Level Service sets the current start level, assigns a bundle to a start level and interrogates the current settings.
  • URL Handler – The Java environment supports a provider model for URL handlers. However, this is a singleton making it impossible to use this in a collaborative environment like OSGi that potentially has many different providers. This service specification enables any component to provide additional URL handlers.

SYSTEM SERVICES

System Services provide horizontal functions that are necessary in virtually every system. The Log Service, Configuration Admin Service, Device Access Service, User Admin Service, IO Connector Service and Preferences Service are examples of system services.

  • Log Service – The logging of information, warnings, debug information or errors is handled through the Log Service. It receives log entries and then dispatches these entries to other bundles that subscribed to this information.
  • Configuration Admin Service – This service provides a flexible and dynamic model to set and get configuration information.
  • Device Access Service – Device Access is the OSGi mechanism to match a driver to a new device and automatically download a bundle implementing this driver. This is used for Plug and Play scenarios.
  • User Admin Service – This service uses a database with user information (private and public) for authentication and authorization purposes.
  • IO Connector Service – The IO Connector Service implements the CDC/ CLDC javax. microedition.io package as a service. This service allows bundles to provide new and alternative protocol schemes.
  • Preferences Service – This service provides access to hierarchical database of properties, similar to the Windows Registry or the Java Preferences class.
  • Component Runtime – The dynamic nature of services -- they can come and go at any time -- makes writing software harder. The Component Runtime specification can simplify handling these dynamic aspects by providing an XML based declaration of the dependencies.
  • Deployment Admin – The primary deployment format for OSGi is the bundle, which is a JAR/ZIP file. The Deployment Admin provides a secondary format: the deployment package. Deployment Packages can combine bundles with arbitrary resources into a single deliverable that can be installed and uninstalled. A comprehensive model of resource processors allows user code to extend the resource types.
  • Event Admin – Many OSGi events have specific typed interfaces, making it hard to receive and filter events generically. The Event Admin provides such a generic, topic-based event mechanism. The specification includes mapping for all existing framework and service events.
  • Application Admin – The OSGi bundle model is different from the typical desktop or mobile phone application model that relies on starting and stopping applications. The Application Admin prescribes such a traditional application model and its required management infrastructure.

PROTOCOL SERVICES

The OSGi Alliance has defined a number of services that map an external protocol to an OSGi service.

  • Http Service – The Http Service is, among other things, a servlet runner. Bundles can provide servlets, which becomes available over the Http protocol. The dynamic update facility of the OSGi Service Platform makes the Http Service a very attractive web server that can be updated with new servlets, remotely if necessary, without requiring a restart.
  • UPnP Service – Universal Plug and Play (UPnP) is an emerging standard for consumer electronics. The OSGi UPnP Service maps devices on a UPnP network to the Service Registry. Alternatively, it can map OSGi services to the UPnP network. This is a recommended Release 3 specification.
  • DMT Admin – The Open Mobile Alliance (OMA) provides a comprehensive specification for mobile device management on the concept of a Device Management Tree (DMT). The DMT Admin service defines how this tree can be accessed and/or extended in an OSGi Service Platform.

MISCELLANEOUS SERVICES

  • Wire Admin Service – Normally bundles establish the rules to find services that they want to work with. However, in many cases this should be a deployment decision. The Wire Admin service therefore connects different services together as defined in a configuration file. The Wire Admin service uses the concept of a Consumer and Producer service that interchange objects over a wire.
  • XML Parser Service – The XML Parser service allows a bundle to locate a parser with desired properties and compatibility with JAXP.
  • Initial Provisioning
  • Foreign Application Access

CONCLUSION

The OSGi specifications are so widely applicable because the platform is a small layer that allows multiple Java™ based components to efficiently cooperate in a single Java Virtual Machine (JVM). It provides an extensive security model so that components can run in a shielded environment. However, with the proper permissions, components can reuse and cooperate, unlike other Java application environments. The OSGi Framework provides an extensive array of mechanisms to make this cooperation possible and secure.

The presence of OSGi technology-based middleware in many different industries creates a large software market for OSGi software components. The rigid definition of the OSGi Service Platform enables components that can run on a variety of devices, from very small to very big.

Adoption of the OSGi specifications can therefore reduce software development costs as well as provide new business opportunities.

FURTHER READING

There are more documents to to be found in our Links page.