Published on

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. OSGiThe Dynamic Module System for JavaTM
  2. 2. OSGi Motivation Growing complexity requires not only highly modularcode, but also systems that are dynamically extensible Because there should be simpler way to construct softwaresystems than writing , writing, and writing … No matter which problem domain is your area of concern◦ Embedded systems need to adapt to changing requirements eventhough they are deployed out in the field◦ Server applications must be configurable and manageablewithout down time◦ Client applications must respond to user desires for newfunctionality instantaneously
  3. 3. OSGi Problems to Adders Lack of Portability Stale Devices Software Size Software Complexity Limits OO Technology Quality of Service
  4. 4. OSGi Background Started as an embedded platform for the “homegateway” Originally under the JCP as JSR-8 (1999) Maintained by OSGi alliance, consists of a largenumber of big companies. Current version: OSGi Release 4.2 (JSR-294)
  5. 5. OSGi Introduction An interesting platform for creating dynamicallyextensible applications Provides a service-oriented, component basedenvironment Offers standardized ways to manage thesoftware lifecycle. OSGi technology is Universal Middleware.
  6. 6. OSGi What we can achieve Resolves many deficiencies associated withconventional approaches for modularity anddynamism◦ Provide a module concept Explicit sharing of code (i.e., importing and exporting)◦ Automatic management of code dependencies Enforces sophisticated consistency rules for classloading◦ Life-cycle management Manages dynamic deployment and configuration
  7. 7. OSGi Architectural Overview
  8. 8. OSGi Framework LayersL3 - publish/find/bind service model todecouple bundlesL2 - independent life-cycle of bundles withoutJVM restartsL1 - a module (or bundle) uses classes fromother bundles in a controlled wayL0 - well defined profiles that define theenvironment in which bundles can work
  9. 9. OSGi ModuleLayer Unit of deployment is bundle, a JAR Separate class loader per bundle Multi-version support (side-by-side) Explicit code boundaries anddependencies Metadata in the manifest Automatic wiring based on versionranges
  10. 10. OSGi Life-cycleLayer Managed life cycle◦ States for each bundle; Allows updates of existingbundles.◦ Dynamicallyinstall, start, update, anduninstall
  11. 11. OSGi ServiceLayer Service interfaces allow bundles tointeract by binding interfaces, notimplementations Publish/find/bind intra-VM servicemodel
  12. 12. OSGi Dynamic Service LookupOSGi FrameworkProvided ServiceProvided Packageinstallbundle.jarAutomatic packagedependency resolutionManual servicedependency resolutionExistingBundleInstalledBundleResolv-edBundleresolve bundle
  13. 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 Applications configuration is simply the set ofdeployed bundles◦ Deploy only the bundles that you need
  14. 14. OSGi Paint Program Create a simple Swing-based paint program Define a SimpleShape interface to draw shapes◦ Different implementations of SimpleShape can becreated 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 thenclick in the drawing canvas◦ Shapes can be dragged, but not resized Support dynamic deployment of shapes
  15. 15. OSGi High Level ArchitectureBest practice – Try tocentralize interactionwith OSGi API so thatother componentsremain POJOs...onlyShape Tracker willinteract with OSGi API.Best practice – Do notmake assumptionsabout threads...since weare creating a Swingapplication, ShapeTracker sends events onSwing thread.Main applicationwindow – getsdynamically injectedwith available shapesfrom the ShapeTracker..Actual shapeimplementation.Injected “proxied” shapeimplementation to hideaspects of dynamismand provide a defaultimplementation.Component that draws theshape in parent frame; looksup shape via Drawing Framerather than having a directreference..
  16. 16. OSGiDEMO
  17. 17. OSGi Adoption Applications can leverage OSGifunctionality in two ways◦ Bundled application Build entire application as a set of bundles that willrun on top of a framework instance◦ Hosted framework Host a framework instance inside the applicationand externally interact with bundles/services
  18. 18. OSGi Adoption (Bundled vs Hosted) Building your application as a set of bundles isthe preferred approach◦ Allows all parts of application to benefit from OSGimodularity and dynamism◦ Allows application to run on any framework◦ However, it is not always possible to bundleapplication, e.g., legacy situations Hosted framework approach allows piecemealOSGi adoption◦ Will likely tie application to a frameworkimplementation