Explorations into OSGi on the server side

1. 10 Questions & Answers on
OSGi (on the server side)
Toralf Richter, May 11, 2009

2. 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)

3. 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)

4. 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)

5. 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

6. 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 OSGi
Specification 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 8. How does an OSGi manifest
look?
Key elements of an OSGi JAR MANIFEST below.
MANIFEST is to be found in jar:<xyz>!/METAINF/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.webf
leet;version=“[2.0.0, 2.1.99)“
Private-Package: com.tomtomwork.internal.*

14. 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

15. 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)

16. 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

17. Thanks for your patience.
Toralf Richter
toralf.richter@tomtom.com
http://de.linkedin.com/in/toralfrichter/
@ToralfRichter