OSGi is a module system and service platform for Java that provides dynamic module capabilities. It addresses issues with traditional Java applications like lack of portability, software complexity and size, and limits on object oriented technologies. OSGi allows applications to be constructed as a set of reusable modules (bundles) that can be dynamically installed, started, stopped, updated, and uninstalled without requiring a reboot. It uses a publish/find/bind model where bundles export and import packages and can discover and bind to services from other bundles at runtime.

1. OSGi
The Dynamic Module System for JavaTM

2. OSGi Motivation
 Growing complexity requires not only highly modular
code, but also systems that are dynamically extensible
 Because there should be simpler way to construct software
systems than writing , writing, and writing …
 No matter which problem domain is your area of concern
◦ Embedded systems need to adapt to changing requirements even
though they are deployed out in the field
◦ Server applications must be configurable and manageable
without down time
◦ Client applications must respond to user desires for new
functionality instantaneously

3. OSGi Problems to Adders
 Lack of Portability
 Stale Devices
 Software Size
 Software Complexity
 Limits OO Technology
 Quality of Service

4. OSGi Background
 Started as an embedded platform for the “home
gateway”
 Originally under the JCP as JSR-8 (1999)
 Maintained by OSGi alliance, consists of a large
number of big companies.
 Current version: OSGi Release 4.2 (JSR-294)

5. OSGi Introduction
 An interesting platform for creating dynamically
extensible applications
 Provides a service-oriented, component based
environment
 Offers standardized ways to manage the
software lifecycle.
 OSGi technology is Universal Middleware.

6. OSGi What we can achieve
 Resolves many deficiencies associated with
conventional approaches for modularity and
dynamism
◦ Provide a module concept
 Explicit sharing of code (i.e., importing and exporting)
◦ Automatic management of code dependencies
 Enforces sophisticated consistency rules for class
loading
◦ Life-cycle management
 Manages dynamic deployment and configuration

7. OSGi Architectural Overview

8. OSGi Framework Layers
L3 - publish/find/bind service model to
decouple bundles
L2 - independent life-cycle of bundles without
JVM restarts
L1 - a module (or bundle) uses classes from
other bundles in a controlled way
L0 - well defined profiles that define the
environment in which bundles can work

9. OSGi Module
Layer
 Unit of deployment is bundle, a JAR
 Separate class loader per bundle
 Multi-version support (side-by-side)
 Explicit code boundaries and
dependencies
 Metadata in the manifest
 Automatic wiring based on version
ranges

10. OSGi Life-cycle
Layer
 Managed life cycle
◦ States for each bundle;
 Allows updates of existing
bundles.
◦ Dynamically
install, start, update, and
uninstall

11. OSGi Service
Layer
 Service interfaces allow bundles to
interact by binding interfaces, not
implementations
 Publish/find/bind intra-VM service
model

12. OSGi Dynamic Service Lookup
OSGi Framework
Provided Service
Provided Package
install
bundle.jar
Automatic package
dependency resolution
Manual service
dependency resolution
Existing
Bundle
Installed
Bundle
Resolv
-ed
Bundle
resolve bundle

13. OSGi OSGi Service Advantages
 Lightweight services
◦ Direct method invocation
 Good design practice
◦ Separates interface from implementation
◦ Enables reuse, substitutability, loose coupling, and late binding
 Dynamic
◦ Loose coupling and late binding make it possible to support run-
time dynamism
 Application's configuration is simply the set of
deployed bundles
◦ Deploy only the bundles that you need

14. OSGi Paint Program
 Create a simple Swing-based paint program
 Define a SimpleShape interface to draw shapes
◦ Different implementations of SimpleShape can be
created to draw different shapes
◦ Each shape has name and icon properties
◦ Available shapes are displayed in tool bar
 To draw a shape, click on its button and then
click in the drawing canvas
◦ Shapes can be dragged, but not resized
 Support dynamic deployment of shapes

15. OSGi High Level ArchitectureBest practice – Try to
centralize interaction
with OSGi API so that
other components
remain POJOs...only
Shape Tracker will
interact with OSGi API.
Best practice – Do not
make assumptions
about threads...since we
are creating a Swing
application, Shape
Tracker sends events on
Swing thread.
Main application
window – gets
dynamically injected
with available shapes
from the Shape
Tracker..
Actual shape
implementation.
Injected “proxied” shape
implementation to hide
aspects of dynamism
and provide a default
implementation.
Component that draws the
shape in parent frame; looks
up shape via Drawing Frame
rather than having a direct
reference..

16. OSGi
DEMO

17. OSGi Adoption
 Applications can leverage OSGi
functionality in two ways
◦ Bundled application
 Build entire application as a set of bundles that will
run on top of a framework instance
◦ Hosted framework
 Host a framework instance inside the application
and externally interact with bundles/services

18. OSGi Adoption (Bundled vs Hosted)
 Building your application as a set of bundles is
the preferred approach
◦ Allows all parts of application to benefit from OSGi
modularity and dynamism
◦ Allows application to run on any framework
◦ However, it is not always possible to bundle
application, e.g., legacy situations
 Hosted framework approach allows piecemeal
OSGi adoption
◦ Will likely tie application to a framework
implementation