OSGi Overview TomTom DevDay May 2009

10 Questions & Answers on OSGi (on the server side)

Toralf Richter, May 11, 2009

1. What is OSGi?

Answer 1 An acronym : Open Services Gateway initiative

Answer 2 The name of a consortium : the „OSGi Alliance“ Founded 1999 more than 100 companies as members world-wide

(IBM, Oracle+Sun, Nokia, and many telcos, automotive equipment manufacturers)

1. What is OSGi?

Answer 3 a specification : the OSGi Service Platform defines basic concepts of OSGi components and services terminology: bundle, life cycle, services, dependencies defines a programming interface (API) to interact with

the service platform, other services in the same platform, etc.

defines how bundles (components) are built and how their needed meta information is added

current specification version is R4.1 (since May 2007)

1. What is OSGi?

Answer 4 a set of paradigms : in some sense OSGi is yet another incarnation

of the component architecture - complex software systems (should) consist of simpler building blocks (components) OSGi bundles

service orientation within the application - components exists besides each other and express dependency but true interaction is by services using a producer-consumer pattern

It is fine-grained (versus monolithic) - the building blocks are loosely coupled and ought to never rely on another building block‘s presence

it is dynamic – services can appear and disappear (white board pattern)

It aims at continuous operation (uninterrupted by updates and maintenance)

2. Origins of OSGi

Mainly from the embedded software development in automotive (think of BMW iDrive), mobile (think of Java on mobile phones), home entertainment (many recent DVD players run on

OSGi bundled Java applications

3. So what is the server-side story with OSGi? Drive to „enterprise OSGi“ recognisable Foundation of OSGi Enterprise Expert Group in January

2007 transport Java EE APIs and functionalities to OSGiSpecification R4.2 due June 2009 will contain “enterprise

features” which will make OSGi much more practicable (than now) for large scale server side applications

Initial attempt at “distributed OSGi” We made some studies into OSGi for server

applications starting from 2007/2008 this but it only starts to get really interesting now

4. How mature can we consider it on the server side? Some examples of server / server-infrastructure

applications built on OSGi already JBoss, Glassfish v3, BEA Weblogic

Mule ESB, Apache ServiceMix ESB

For the typical JEE application there are still shortcomings of the specification and available and possible implementations.

It seems this is going to improve with R 4.2

OSGi on the server side can currently be considered a heavily emerging technology

5. What are the basic principles? Software is made of components Each component has a clearly marked functionality

(„core competency“) The „same“ component can be present in several

versions In OSGi components are called bundles

5. What are the basic principles? OSGi compliant componentised software runs in a

suitable runtime environment called an “OSGI framework” or “OSGI container”

The container takes care of interpreting the meta information attached to the components, i.e. provide the export and requests the imports (quite similar to well know web or JEE containers)

It takes care choosing a suitable isolation level between bundles based in meta information, in effect determining “visibility” between bundles

5. What are the basic principles? Complex applications are composed of bundles and the dependencies

expressed between them Dependencies can be direct export / import relationship Fragment relationship Service producer /

service consumer relationship

The container resolves dependencies from the “visible” offerings deployed in the container

6. How to manage visibility? Bundles specify explicitly what (Java) packages they provide to other bundles, the OSGi

term for this is export what packages or entire other bundles are needed, or in OSGi

terms are imported and what packages are kept strictly private, etc.

In addition to Java code level visibility (public, protected, …) visibility between bundles is determined by package exports and their version information

The OSGi container takes care of dependency resolution (I.e. does export meet import)

An importer of a package does usually not care which exporter actually provides package, alternatives / substitutes of the same functionalities / exports are easily interchangeable

7. How to express version constraints? Version number pattern „major.minor.bugfix.qualifier“ Exports specify the version they provide Imports specify the precise version or version

range they require Specifying range in the manifest is done in

“mathematical notation” : [ means >=, ] means <=, ( means >, ) means <

Example range: from including 1.5.0 to not including 2.0 - manifest notation: version=“[1.5.0, 2.0)”

When more than one bundle or package match an importers version constraint there are decisions rules (set by OSGi specification) which one goes first

8. How does an OSGi manifest look?

Key elements of an OSGi JAR MANIFEST below. MANIFEST is to be found in jar:<xyz>!/META-INF/MANIFEST.MF

Bundle-SymbolicName: ttwBase

Bundle-Version: 1.0.0

Bundle-Activator: com.tomtomwork.base.Activator

Require-Bundle: ttwOther;bundle-version=“[1.3.1, 1.4.0)“

Export-Package: com.tomtomwork.base.*;version=“1.0.0“

Import-Package: org.osgi.framework;version="1.3.1“,com.tomtomwork.webfleet;version=“[2.0.0, 2.1.99)“

Private-Package: com.tomtomwork.internal.*

9. How bundles interact using services? bundles can register objects they instantiate and hold as

services they become service providers or service producers when registering service the provider specifies a service interface

and arbitrary additional (meta) information and announces the service(s) on a public white board (service registry)

also bundles can lookup services fulfilling certain criteria and when available consume the service

provider and consumer do not and should not know each other. They interact through the white board (service registry)

loose coupling + dynamism: (non-)availability of services can be queried “per-access”, notifications can be set up using service listeners, and since specification R 4.x the service tracker can be used for constant and transparent service state tracking

10. What are advantages and costs of OSGi development? Developer must learn new API plain OSGi partially invasive on code (can be avoided

using declarative services) developer MUST honour OSGi paradigms third party libraries are sometimes not yet OSGi

complaint tooling not yet “up to speed” when you compare it to

standard Java IDE products JEE capabilities still emergent (e.g. complex /

multiple web applications or JDBC still somewhat complicated)

10. What are advantages and costs of OSGi development? robust

clearly defined and managed dependencies

code quality / maintainability bundles can and should be developed separately and interact on

defined interfaces … this helps to avoid growing huge tangled monoliths

flexibility / adaptability Composed arbitrarily complex applications from small bundles

focusing on their “core competency”

(high) availability / continuous operation update / swap bundles without rebooting the entire application

container (“hot deploy” is rather default mode of operation instead an option)

extensibility add bundles and capabilities at runtime

Thanks for your patience.

Toralf Richter

toralf.richter@tomtom.com

http://de.linkedin.com/in/toralfrichter/

@ToralfRichter