1 / 26

A Peek at the Next Release: OSGi

A Peek at the Next Release: OSGi. BJ Hargrave and Peter Kriens hargrave@us.ibm.com Peter.Kriens@aQute.biz OSGi Fellows. General Requirements. Backward compatible Transparent Life cycle aware Optional Focus on embedded systems Flexibility. Service & Resource Arbitration. Problem

varuna
Download Presentation

A Peek at the Next Release: OSGi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Peek at the Next Release: OSGi BJ Hargrave and Peter Kriens hargrave@us.ibm.com Peter.Kriens@aQute.biz OSGi Fellows

  2. General Requirements • Backward compatible • Transparent • Life cycle aware • Optional • Focus on embedded systems • Flexibility

  3. Service & Resource Arbitration • Problem • Multiple clients need to use the same service but the service can not be (partly) shared • Use case • Telephone used in normal operation when an emergency call need to be made. How is the current user of the telephone notified? • The audio system is used by he nav system when a phone call comes. The nav system must give up the audio system until the call is finished. • Requirements • Session Management: Grant deny, terminate, suspend, resumed, abort • As transparent as possible • Notifications about resource usage changes

  4. Resource Management • Problem • A system must carefully manage its resource usage (memory, cpu cycles, threads, etc.) by bundles to guarantee the correct operation of the service platform. • Use case • A bundle is to be installed. The bundle is interrogated for its persistent storage requirements. This are compared with the available storage. There is sufficient storage and the bundle is installed. • Requirements • Ability to describe and check resource requirements of a bundle • Notification of exceeding resource allocation • Monitoring of allocated resources

  5. Power State Notification • Problem • Bundles need to be able to react to imminent power state changes to: • Maintain integrity • Conserve energy. • Use case • The navigation system has a display and a CD-ROM drive. When the car goes to battery mode, the CD-ROM and display need to be powered down. When the engine is started, the CD-ROM and display can be powered up. • Requirements • Allows monitoring of power states in (near) real time • Note: May be realized by the creation of a general event delivery mechanism with specific power state events.

  6. Diagnostics Support • Problem • Need a generalized mechanism to perform diagnostics on services and devices connected to the service platform • Use case • Navigation system is sometimes displaying incorrect map data. The car is taken in for service and the technician has a diagnostic bundle installed. The diagnostic bundle performs tests on all the connected devices and determines the GPS has a memory error. • Requirements • Request self test of device • Monitor/collect device data • Change device parameters

  7. CECED & EHS • Problem • EHS is a highly popular power line bus in Europe for home automation and CECED is an abstraction of busses like EHS. Whitegood devices connected to such buses need to be supported in the OSGi environment. • Use case • User buys a washing machine and connects it up in home. The OSGi gateway discovers this device on the powerline network and installs a bundle for the device. The bundle collects information from the washing machine and sends it to the manufacturer. The manufacturer, can now perform remote diagnostics if necessary. • Requirements • Provide low level API to support communication between bundle and device • Note: Need to agree on CECED vs. EHS as abstraction

  8. Web Container • Problem • The OSGi SP as an application server has several advantages over a J2EE environment. J2EE web applications should therefore run on OSGi SP without much effort. • Low level web site development with the servlet API requires skilled (expensive) programmers. Content developed for OSGi based platforms should be able to leverage existing web development tools • Use case • A developer uses WSAD to create a web application using servlets and JSPs. This application can be test using WSAD. The resulting WAR file is preprocessed by a tool that converts it to a bundle. This bundle is installed and the web application can then be accessed. • Requirement • Use of standard web application development tools • Pre-compilation of JSPs

  9. Bundle Suite • Problem • Sometimes bundles are not standalone but work with other bundles to form an application • Use case • An application developer creates an application which is composed of several bundles. These bundles share packages and services and are closely coupled. An application assembler wants to assemble the complete application (all necessary bundles) in one deliverable. It therefore needs a standard artifact to hold the bundles and their associated metadata. • Requirement • Define a flexible, extensible file format for delivery • Support localization

  10. Transient Bundles • Problem • OSGi bundles are always permanently installed. Sometimes this is not desirable since a bundle may only be necessary for a very short time. After this it should be removed reliably. • Use case • A bundle containing a GPS firmware update is installed in the OSGi device of a car. The bundle is started and updates the firmware on the GPS. After this, the bundle is no longer needed and can be uninstalled. • Requirement • Allow framework to avoid persistent storage of transient bundles • Automatically remove transient bundle when framework stopped/restarted for reliability reasons

  11. Allow Bundles To Change Their State • Problem • A certain class of bundles can determine when they can be stopped or uninstalled. However, the OSGi framework forbids these bundles to stop/update/uninstall themselves because the calls are synchronous. • Use case • A technician must diagnose a car and loads a bundle in the platform. IT performs the diagnosis and after this diagnosis is performed, the bundle is no longer necessary. • Requirement • Provide an asynchronous mechanism for bundle to request to be uninstalled, updated or stopped.

  12. Enumeration of Resources Within a Bundle • Problem • Resources contained in a bundle cannot be discovered in runtime, requiring that the application to have a-priori knowledge of the content. Many patterns exist where applications can adapt to included content dynamically. These patterns can currently not be used. • Use case • A web container bundle implementing the Servlet (2.3) API needs to implement the ServletContext.getResourcePaths method. This method allows a web application to examine its contained resources. • Requirement • Provide a method that can be called to enumerate the resources in a bundle.

  13. Code Matching Enhancements • Problem • The native code is only selected by OS, processor and language. In certain cases, this set is not sufficient to make the correct decision. A richer selection algorithm is necessary. • There are sometimes platform dependencies on pure Java code requiring alternative implementations. There is currently no means to selectively load these implementations. • Use case • Eclipse GUI (SWT) requires native code and a Java library. For Unix, it can run on Motif and X requiring a specific native code library and swt.jar for each. Bundles can carry the alternatives and right shared library and jar file is selected in run time. • Requirement • A general and extensible mechanism to select components in the Bundle-NativeCode and Bundle-Classpath header • Reuse existing selection techniques.

  14. Optional Native Libraries • Problem • Some Native libraries may not be required for all platforms because there is a fallback mechanism when the native library does not exist. Currently if a native library is specified, a library must exist for the specific platform or the installation will completely fail. • Use case • A bundle provides a crypto API to other bundles. This bundle contains an all Java implementation of the crypto API so that it operates on all platforms. The bundle also contains native implementations of the crypto library for some platform as a performance enhancement. • Requirement • Installation of a bundle must (optionally) succeed if a native library is not available

  15. Life Cycle Transactions • Problem • Certain bundle installations can be dependent upon each other. In those cases it is necessary to install all or none of the bundles. • Use case • A feature (made up of one or more bundles) is to be installed via the Eclipse update manager. The update manager creates a bundle life cycle transaction object. It then performs bundle installations, updates and uninstalls against the transaction. If all the operations are performed without an exception, the update manager commits the transaction. • Requirement • Bundle life cycle operations can be grouped and validated for success before being committed

  16. Singletons • Problem • There are times when it is appropriate that only a single version of a bundle, service or a package is present in the framework • Use case • A bundle provides the UI framework for the device. There is only one display on the device and correspondingly there should only be one bundle providing the UI framework. The bundle is marked a singleton so the framework can prevent attempts to install or use another version of the bundle. • Requirement • Detect and prevent multiple versions being present at the same time

  17. Bundle as Module • Problem • Bundles need to share classes based upon implementation versions. Current class sharing is based upon package exporting by specification version. Many time the packages to be shared are not well specified and really contain implementation details. It may also be the case that these packages should not be globally exported to all bundles. • Use case • The xerces parser consists of many packages which contain the implementation of the parser. The developer specifies that his bundle is dependent on the xerces bundle as a module using some versioning constraints (e.g. = 4.1.*). When the developer’s bundle is resolved, its class loader will then have access to all the implementation packages in the xerces bundle. • Requirement • Allow bundles to share classes based upon the implementation versions of the bundles

  18. Bundle Fragments • Problem • Sometimes bundles can be composed of parts which do not always have to be deployed at the same time but are still strongly coupled • Use case • A bundle developer seperates the national language message catalogs from the base bundle into a set of bundle fragments, one per national language. The base bundle and some set of the corresponding fragments are installed. The message catalogs in all the installed fragments are now loadable by the base bundle. • Requirement • Provide a way for a bundle to be logically extended (within same classloader) by separately installed components

  19. Export Multiple Versions of a Package • Problem • In large systems, installed applications can depend upon different versions of the same package • Use case • Bundle A depends upon version 2.1 of the servlet API. Another application in bundle B is dependent upon version 2.3 of the servlet API. Neither bundle can work with the other version of the API. Both bundles can be run and are bound to the proper version of the API. • Requirement • Multiple versions of the same package can be exported • Bundles can bind to specific versions of an exported package • Bundles bound to different versions of a package cannot exchange object or detect services between each other to avoid ClassCastException

  20. Different Package Specification Major Versions are defined to be Non Compatible • Problem • Sustain backwards compatibility over major specification version changes is not always feasible for larger systems. • Use case • The specification for a package is updated to a new major version. The update introduces a non-backwards compatible change because a method is removed. A bundle which imports the package at an earlier major version is not exposed to the new major version of the package. • Requirement • Interpret specification version numbers according to a major.minor.micro scheme with major version changes being non-compatible

  21. Filter packages from Base ClassLoader • Problem • The base java platform may include packages which cannot be updated by a bundle • Use case • The J2SE installation provides a version of Xerces and the org.w3c.dom and org.xml.sax packages. These packages are an older version that the one needed by bundles running in the framework. So we want to install a bundle which exports a newer version of these packages. The framework must be configured to “hide” the old version of these packages from all bundles, so that the new versions of the packages can be instead used. • Requirement • Allow specific package provided by the base classloader to be overridden by bundles

  22. Version Overrides • Problem • Version constraints expressed by bundle developer may cause the installed bundle set to be unresolvable. Though in reality these bundles could operate correctly with the provided versions. • Use case • Bundle A is written and specified to require bundle B version 1.2 or higher. When installing the bundle, the management agent is informed by the management system that bundle A has been tested successfully and will work with bundle B version 1.1 which is already installed. So that management agent overrides the required version information and the framework will resolve bundle A using bundle B version 1.1. • Requirement • Allow management agent to override version constraints

  23. Demand Loading of Services from Bundles • Problem • Registering a service from a bundle requires the bundle to have a classloader, be started and explicitly register a service. This requires significant resources before the service is ever used. • Use case • A bundle containing an XML parser implementation wishes to register SaxParserFactory and DocumentBuilder services to allow other bundles to use the parser. The bundle declaratively specified these services. The framework will automatically load and start the bundle when someone requests the service. • Requirement • Allow bundle to declare services to be registered • Start bundles on demand when services are obtained

  24. Dynamic Extensions to the Service Registry • Problem • In many cases services may be provided by external service registry where it is not feasible to preregister all the external services in the local OSGi service registry because of performance • Use case • A bundle attempts to find a service. The service is a web service which is found in a UDDI registry. A bundle which communicates with the UDDI registry will intercept the find request and can then provide services matching the web service. • Requirement • Allow the service find mechanism to be extended to bundles

  25. Finer grained Framework administration permissions • Problem • AdminPermission is too coarse grained. It protects too many different privileged operations. • Use case • HttpService currently requires AdminPermission to call Bundle.getResource to access resources in a bundle. This requires HttpService to be fully trusted and makes it difficult to use 3rd party providers for this simple service. • Requirements • Finer grain replacement for AdminPermission

  26. Bundle Signing • Problem • Currently the integrity and authenticity of bundles must be determined in a proprietary way. This prevents interoperation and tooling support. • Use case • A bundle is installed in the framework. The framework validates the integrity and authenticity of the bundle and completes the install. When the bundle is loaded from the local storage, the framework again validates the integrity and authenticity of the bundle. The permissions for the code in the bundle is assigned based upon the code signers. • Requirements • Allow for standard mechanism to validate the integrity and authenticity of the bundles • Allow permissions for bundles to be assigned based upon the signers of the code

More Related