OSGi

OSGi is a mature component model from the OSGi Alliance. It has implementations from organizations like the Eclipse Foundation with their Equinox framework (McAffer et al., 2010), and the Apache foundation with their framework Felix3.

OSGi components are referred to as bundles, each contains a meta-data file describing the bundle’s constraints, and a set of Java packages and classes as implementation. The OSGi framework separates the components for deployment and run-time into bundles and services respectively. These services exist on a separate layer to the bundles, each service is created at run-time and is represented by a Java object. This service layer can also describe constraints through frameworks like Spring Dynamic Modules4. Under the definition of component in this research, this makes both the bundle layer and the service layer software component models. These layers are discussed here.

3_{http://felix.apache.org/ accessed 6/3/2012} 4

2.4.1.1 Bundle Layer

To show how the bundle meta-data describe constraints of a component, an example is presented in figure 2.1 where a text editor bundle depends on a spell checker.

Bundle-Name: TextEditor Bundle-Vendor: Graham Jenson

Bundle-SymbolicName: nz.geek.textEditor Bundle-Version: 0.0.1.alpha Bundle-RequiredExecutionEnvironment: J2SE-1.4 Export-Package: nz.geek.textEditor;version="0.0.1.alpha" Require-Bundle: nz.geek.fonts Import-Package: nz.geek.spellchecker;version>"0.0.1"

Figure 2.1: Example of OSGi Meta-data

This meta-data shows the name and version of the component, as well as the exported packages (referring to Java packages). Also presented are constraints, such as the necessary execution environment, and the required bundles and packages in the system.

Require-Bundle describes the direct dependence on other bundles, and Import- Package describes the dependence on packages provided by other bundles.

2.4.1.2 Service Layer

This bundle meta-data only contains information necessary for the execution of a component. However, for the component to be functional the service layer of OSGi is used.

The service layer is defined in the core OSGi specification (The OSGi Alliance, 2007b), however its definition does not describe any meta-data format. To help manage services, a number of frameworks have emerged, e.g. Spring Dynamic Modules5. OSGi’s compendium specification (The OSGi Alliance, 2007a) also defines a service layer meta- data format called Declarative Services (DS). To show how the DS meta-data can be used to express constraints on the service layer, an example is presented in figure 2.2. This meta-data includes references to implementation elements (like interfaces) that are provided and required, and methods to interact with the services. The dependency constraints can have cardinalities, e.g. a text editor can use multiple spell checkers.

5

<?xml version="1.0"?> <component name="textEditor"> <implementation class="nz.geek.textEditor.TextEditorImpl"/> <service> <provide interface="nz.geek.textEditor.TextEditor"/> </service> <reference name="spellChecker" interface="nz.geek.spellchecker.SpellChecker" bind="setSpellChecker" unbind="unsetSpellChecker" cardinality="0..1" policy="dynamic"/> </component>

Figure 2.2: Example of OSGi Declarative Services meta-data

The service tag describes the services provided, and the reference tag expresses a dependence on another service.

One aspect lacking in the DS meta-data is the ability to define a version range on constraints. The version of a service is implicitly defined by the version of the bundle that provides the service. However, this implicit version is unable to be reasoned about by DS.

2.4.1.3 OSGi Change

The programmatic evolution of an OSGi system is defined in the interfaces created by the OSGi alliance.6 The installation and removal of both the bundles and services from the OSGi system are:

• To install a bundle: org.osgi.framework.BundleContext#install • To uninstall a bundle: org.osgi.framework.Bundle#uninstall • To register a service: org.osgi.framework.BundleContext#registerService 6 http://www.osgi.org/javadoc/r4v43/ accessed 6/3/2012

• To unregister a service:

org.osgi.framework.ServiceRegistration#unregister

These methods can be used from an implemented console, allowing a user to directly execute them to add or remove bundles.

2.4.1.4 OSGi Bundle Repostiory

To implement CDR functionality for OSGi, in RFC-0112 (The OSGi Alliance, 2006) Peter Kriens and Richard S. Hall proposed the OSGi Bundle Repository (OBR). OBR is an XML format that describes OSGi components, and also an application with CDR functionality. To show how OBR describes component constraints, an example of an OBR document is presented in figure 2.3.

<repository name=’OBR REP’ time=’123’>

<resource version=’0.0.1’ name=’nz.geek.textEditor’ uri=’nz.geek.textEditor.0.0.1.jar’>

<require optional=’false’ multiple=’false’ name=’package’

filter=’(&amp;(package=nz.geek.spellChecker)(version>=1.0.0))’> Import package nz.geek.spellChecker ;version=1.0.0

</require> </resource>

<resource version=’1.0.0’ name=’nz.geek.spellChecker’ uri=’nz.geek.spellChecker-1.0.0.jar’> <capability name=’package’> <p v=’nz.geek.spellChecker’ n=’package’/> <p v=’1.0.0’ t=’version’ n=’version’/> </capability> </resource> </repository>

Figure 2.3: Example of OSGi Bundle Repository meta-data

This meta-data format was designed so that it can merge the bundle and service meta- data together. It also ignores many of the implementation aspects of OSGi bundles and focuses on the constraints of the components. OBR represents only the necessary elements from both OSGi bundle and service layers to provide CDR functionality. OBR has been seen as a solution to simplify deployment of OSGi applications (Jung,

2007), distribution and deployment to embedded ubiquitous systems (Jung and Chen, 2006), smart home applications (Gouin-Vallerand and Giroux, 2007) and dynamic distribution of drivers (Kriens, 2008).

The most mature implementation of an OBR client is offered by the Apache foundation. The client is bundled with their core OSGi framework Apache Felix. This client can be used with any of the large public or private OBR collections of bundles. An example of one such public repository is the Paremus repository7 which contains (as of December 2011) over 2000 bundles.

The specification of OBR does not define a method or parameters used to define preferences when selecting a component system. Therefore, selecting systems, when many are valid, is implementation specific. The method used by the Apache OBR8 implementation to select a system is described on its help page as:

“OBR might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In response to this type of scenario, the OBR deployment algorithm tries to favor updating existing bundles, if possible, as opposed to installing new bundles to satisfy dependencies.”

This shows that when upgrading a system, not installing new bundles is preferred.