1 / 20

OSGi: Open Services Gateway Initiative

OSGi: Open Services Gateway Initiative. Richard Chapman 5 Sept. 2002. Original Intention. To allow services to be remotely deployed and administered onto home network gateways such as set-top boxes and DSL modems. Current Intention.

isleen
Télécharger la présentation

OSGi: Open Services Gateway Initiative

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. OSGi: Open Services Gateway Initiative Richard Chapman 5 Sept. 2002

  2. Original Intention • To allow services to be remotely deployed and administered onto home network gateways such as set-top boxes and DSL modems

  3. Current Intention • Expanded to be a language and OS-neutral way of providing and administering services • Targets include divserse platforms such as automotive components, comsumer electronics, mobile phones

  4. OSGi Appropriate where • Lifecycles are managed • Uptimes are long • Management is done remotely • Resilience, robustness matters • (this is the marketing hype)

  5. What is it • A Java-based environment consisting of the J2RE and the OSGi framework in which downloadable bundles of services managed by a registry can be run

  6. Supposedly plays well with other services Insert picture from the overview here

  7. Definitions • Service framework = execution environment for downloaded services • Bundles = groups of downloadable services (related in some way) • Registry = exhange services between bundles in some manner

  8. OSGi Insert picture from p. 7-282

  9. Three version 1 services Logging service Web server Device access Version two services added: Configuration svc Preferences svc User admin svc Permission admin svc Pkg admin svc OSGi Service Specifications

  10. Framework • Allows the downloading, execution, and removal of bundles • M anages bundle installation and updates dynamically (scalably?) • Consistent programming model for bundle developers • Bundles can select an available implementation at runtime through the framework registry

  11. Bundles • JAR files • May include other resources (html, help files, icons, etc) • Contains manifest • States dependencies on other resources • Bundle activator class

  12. Bundles, cont’d • Framework itself is a bundle (system bundle) • Management bundles implement policies (e.g. from what location is a bundle to be loaded) • Each bundle has a classloader with it, providing bundle with own namespace, permitting sharing of packages between bundles

  13. Native Code Libraries • Specified in manifest header • Certain permissions required to load native code library • Can specify different native code for different OS and processor (in the manifest header)

  14. Identifier B undle location Bundle state (installed, active, starting, stopping, active, etc) Bundle Object

  15. Bundle Context • Created by framework when a bundle is started • Represents execution environment of a single bundle • Acts as proxy to underlying framework • Provides private persistent storage area • Maintains environment properties

  16. Services • Bundle is a set of cooperating services available from shared service registry (bundle does the registering) • Services provided in framework as service objects • Service interface defines semantics of a service • Framework manages dependencies between services provided and used by different bundles

  17. Service Interfaces • Service interface is the specification of the service’s public methods • Some defined as standards by OSGi EG’s (expert groups) • Can define your own interfaces (? ) • When requesting a service, you specify the name of the service interface you are interested in implementations of

  18. Registering services • Service object is registered with registry, along with key/value pairs used in searching (like Jini) • Every registered service object has unique ServiceRegistration object (provided only to the bundle that registered the svc) and some ServiceReference objects that refer to the registered service (used to acquire the code when you are ready to use the service)

  19. Obtaining Services • Bundle asks for services implementing an interface, gets ServiceReference Objects back from the registry • Use the ServiceReference object to actually get the service object (you need permission to do that; anyone can get the reference object)

  20. What have I not covered • Events • Security • Using on JDK1.1 • Particular service specifications • What runs on what machine? • LAN, WAN, what?

More Related