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