OSGi
Download as PPTX, PDF1 like498 views
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.
OSGi
- 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
- 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