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
OSGi Problems to Adders Lack of Portability Stale Devices Software Size Software Complexity Limits OO Technology Quality of Service
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)
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.
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
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
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
OSGi Life-cycleLayer Managed life cycle◦ States for each bundle; Allows updates of existingbundles.◦ Dynamicallyinstall, start, update, anduninstall
OSGi ServiceLayer Service interfaces allow bundles tointeract by binding interfaces, notimplementations Publish/find/bind intra-VM servicemodel
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
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
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..
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
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