Osgi Sun 20080820

2,665 views
2,554 views

Published on

Overview of OSGi by the lead of the Apache Felix project

Published in: Technology, Education
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,665
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
204
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Osgi Sun 20080820

  1. 1. OSGi Service Platform: Java Modularity and Beyond Richard S. Hall Sun Microsystems Santa Clara August 20th, 2008
  2. 2. Agenda OSGi Service Platform Overview OSGi as a Java Modularity Layer Majority of the presentation OSGi as a Service-Oriented Application Framework Apache Felix Advertisement Conclusion
  3. 3. OSGi Service Platform Overview
  4. 4. OSGi Alliance Formerly the Open Services Gateway Initiative Industry consortium Defines OSGi Service Platform specification Two parts Framework specification for hosting dynamically downloadable services Standard service specifications Several expert groups define the specifications Core Platform Expert Group (CPEG) – framework Mobile Expert Group (MEG) – mobile telephony Vehicle Expert Group (VEG) – automobile Enterprise Expert Group (EEG) – enterprise issues Residential Expert Group (REG) – gateway devices
  5. 5. OSGi Architectural Overview Bundle k or ew am Fr OSGi Java Operating System Driver Driver Driver Hardware
  6. 6. OSGi Framework Module-oriented framework Bundles (i.e., modules) Package sharing and version management Separate class loader per bundle Class loader graph, independent namespaces Life-cycle management and notification Service-oriented development model Single JVM instance Publish/find/bind intra-VM service model Open remote management architecture No prescribed policy or protocol Explicit support for run-time dynamism Java Permissions used to secure framework
  7. 7. OSGi Framework Layering Execution L0 - •OSGi Minimum Execution Environment Environment CDC •CDC/Foundation CDC •JavaSE
  8. 8. OSGi Framework Layering L1 - Creates the concept of modules (aka. bundles) that use classes from MODULE each other in a controlled way according to system and bundle constraints Execution L0 - •OSGi Minimum Execution Environment Environment CDC •CDC/Foundation CDC •JavaSE
  9. 9. OSGi Framework Layering L2 - Manages the life cycle of bundle in LIFECYCLE a bundle repository without requiring the VM be restarted L1 - Creates the concept of modules (aka. bundles) that use classes from MODULE each other in a controlled way according to system and bundle constraints Execution L0 - •OSGi Minimum Execution Environment Environment CDC •CDC/Foundation CDC •JavaSE
  10. 10. OSGi Framework Layering L3 – Provides a publish/find/bind SERVICE MODEL service model to decouple bundles L2 - Manages the life cycle of bundle in LIFECYCLE a bundle repository without requiring the VM be restarted L1 - Creates the concept of modules (aka. bundles) that use classes from MODULE each other in a controlled way according to system and bundle constraints Execution L0 - •OSGi Minimum Execution Environment Environment CDC •CDC/Foundation CDC •JavaSE
  11. 11. OSGi Momentum OSGi technology has moved beyond original target domain Initial success story was Eclipse RCP More recent success stories in enterprise scenarios IBM Spring Dynamic Modules BEA Oracle JBoss JOnAS GlassFish
  12. 12. OSGi as a Java Modularity Layer
  13. 13. Standard Java Modularity Limitations (1/2) Limited scoping mechanisms No module access modifier Simplistic version handling Class path is first version found Implicit dependencies Dependencies are implicit in class path ordering Split packages by default Class path approach searches until if finds, which can lead to shadowing or mixing of versions
  14. 14. Standard Java Modularity Limitations (1/2) Limited scoping mechanisms No module access modifier Simplistic version handling Class path is first version found Implicit dependencies Dependencies are implicit in class path ordering Split packages by default Class path approach searches until if finds, which can lead to shadowing or mixing of versions JAR files do have some mechanisms in these areas, but they are insufficient
  15. 15. Standard Java Modularity Limitations (2/2) Low-level support for dynamics Class loaders are complicated to use Unsophisticated consistency model Cuts across previous issues, it is difficult to ensure class space consistency Missing module concept Classes are too fine grained, packages are too simplistic, class loaders are too low level JAR file is best candidates, but still inadequate Modularity is a second-class concept
  16. 16. Standard Java Modularity Limitations (2/2) Low-level support for dynamics Class loaders are complicated to use Unsophisticated consistency model Cuts across previous issues, it is difficult to ensure class space consistency Missing module concept Classes are too fine grained, packages are too simplistic, class loaders are too low level JAR file is best candidates, but still inadequate Modularity is a second-class concept To be fair, Java never intended to provide a module layer, yet...
  17. 17. OSGi Framework Modularity Support However, OSGi resolves these modularity-related deficiencies now (and for a few years) OSGi bundle defines an explicit boundary for a module Bundle metadata explicitly declares versioned dependencies on other code Framework automatically manages bundle code dependencies Framework enforces sophisticated consistency rules for class loading within and among bundles Framework supports dynamic module life-cycle management
  18. 18. Bundle Again, a bundle is a module in OSGi terminology What is a bundle?
  19. 19. Bundle Again, a bundle is a module in OSGi terminology What is a bundle? Simply a JAR file plus module metadata Module metadata is stored in META-INF/MANIFEST.MF Defines what the module provides and requires What does a bundle JAR contain?
  20. 20. Bundle Again, a bundle is a module in OSGi terminology What is a bundle? Simply a JAR file plus module metadata Module metadata is stored in META-INF/MANIFEST.MF Defines what the module provides and requires What does a bundle JAR contain? Java classes (i.e., standard JAR file content) Resources (e.g., configuration files, images, etc.) Native code Embedded JAR files Bundles have their own class path
  21. 21. Bundle Again, a bundle is a module in OSGi terminology What is a bundle? Simply a JAR file plus module metadata Module metadata is stored in META-INF/MANIFEST.MF Defines what the module provides and requires What does a bundle JAR contain? Java classes (i.e., standard JAR file content) Resources (e.g., configuration files, images, etc.) Native code Embedded JAR files Bundles have their own class path If a bundle JAR file doesn't use advanced features, then it can be both a standard JAR file and a bundle at the same time
  22. 22. Bundle Life Cycle install INSTALLED uninstall resolve update uninstall UNINSTALLED RESOLVED start STARTING STOPPING explicit stop automatic ACTIVE
  23. 23. Bundle Life Cycle install INSTALLED uninstall resolve update uninstall UNINSTALLED RESOLVED start Resolving a bundle, resolves STARTING STOPPING its code dependencies explicit stop automatic ACTIVE
  24. 24. Bundle Dependency Resolution The framework automatically resolves dependencies before a bundle is used Matches bundle’s requirements to providers of those requirements Package imports/exports Explicit bundle dependencies Bundle fragment dependencies Ensures consistency of requirements with respect to versions and other constraints If a bundle cannot be successfully resolved, then it cannot be used
  25. 25. Dependency Resolution Illustration A bundle is a module contained in a JAR file Provided package existing bundle OSGi framework
  26. 26. Dependency Resolution Illustration A bundle is a module contained in a JAR file existing bundle install bundle.jar OSGi framework
  27. 27. Dependency Resolution Illustration A bundle is a module contained in a JAR file existing resolve bundle bundle OSGi framework
  28. 28. Dependency Resolution Illustration A bundle is a module contained in a JAR file automatic package dependency resolution existing bundle OSGi framework
  29. 29. Package Dependencies Be aware, bundles express dependencies in terms of packages (typically) This is a somewhat novel approach Why?
  30. 30. Package Dependencies Be aware, bundles express dependencies in terms of packages (typically) This is a somewhat novel approach Why? Mimics import package model already known to developers
  31. 31. Package Dependencies Be aware, bundles express dependencies in terms of packages (typically) This is a somewhat novel approach Why? Mimics import package model already known to developers Specifies what instead of who More flexible Can be resolved from different providers Providers can be refactored
  32. 32. Package Dependencies Be aware, bundles express dependencies in terms of packages (typically) This is a somewhat novel approach Why? Mimics import package model already known to developers Specifies what instead of who More flexible Can be resolved from different providers Providers can be refactored Amenable to metadata generation
  33. 33. OSGi Modularity Functionality (1/7) Multi-version support (i.e., side-by-side versions) Possible to have more than one version of a shared package in memory at the same time Allows multiple applications to run in the same VM or sub-components of a single application to depend on different versions of the same libraries Has impacts on the service-oriented aspects of the OSGi framework For a given bundle, the service registry is implicitly partitioned according to the package versions visible to it
  34. 34. OSGi Modularity Functionality (2/7) Explicit code boundaries and dependencies Bundles explicitly expose internal packages (i.e., export) Exporters export precise package versions Bundles explicitly declare dependencies on external packages (i.e., import) Importers may specify an open or closed version range
  35. 35. OSGi Modularity Functionality (2/7) Explicit code boundaries and dependencies Bundles explicitly expose internal packages (i.e., export) Exporters export precise package versions Bundles explicitly declare dependencies on external packages (i.e., import) Importers may specify an open or closed version range Export-Package: bar; version=quot;1.0.0quot; Import-Package: foo; version=quot;[1.0.0,1.5.0)quot;
  36. 36. OSGi Modularity Functionality (2/7) Explicit code boundaries and dependencies Bundles explicitly expose internal packages (i.e., export) Exporters export precise package versions Bundles explicitly declare dependencies on external packages (i.e., import) Importers may specify an open or closed version range Export-Package: bar; version=quot;1.0.0quot; Import-Package: foo; version=quot;[1.0.0,1.5.0)quot; Support for various sharing policies, e.g, Implementation package with limited backwards compatibility Specification packages with defined backwards compatibility
  37. 37. OSGi Modularity Functionality (3/7) Arbitrary export/import attributes for more control Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributes Exporters may declare attributes as mandatory Mandatory attributes provide simple means to limit package visibility Importers influence package selection using arbitrary attribute matching
  38. 38. OSGi Modularity Functionality (3/7) Arbitrary export/import attributes for more control Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributes Exporters may declare attributes as mandatory Mandatory attributes provide simple means to limit package visibility Importers influence package selection using arbitrary attribute matching Export-Package: foo; Export-Package: foo; version=quot;1.0.0quot;; version=quot;1.0.0quot; myattr=quot;myvaluequot; foo A (myattr=“myvalue”) foo B
  39. 39. OSGi Modularity Functionality (3/7) Arbitrary export/import attributes for more control Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributes Exporters may declare attributes as mandatory Mandatory attributes provide simple means to limit package visibility Importers influence package selection using arbitrary attribute matching Import-Package: foo; version=quot;1.0.0quot;; myattr=quot;myvaluequot; foo A (myattr=“myvalue”) foo C foo B
  40. 40. OSGi Modularity Functionality (3/7) Arbitrary export/import attributes for more control Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributes Exporters may declare attributes as mandatory Mandatory attributes provide simple means to limit package visibility Importers influence package selection using arbitrary attribute matching Import-Package: foo; version=quot;1.0.0quot;; myattr=quot;myvaluequot; foo A (myattr=“myvalue”) foo C foo B
  41. 41. OSGi Modularity Functionality (4/7) Sophisticated class space consistency model In addition to dependency resolution Exporters may declare package “uses” dependencies Exported packages express dependencies on imported or other exported packages, which constrain the resolve process The framework must ensure that importers do not violate constraints implied by “uses” dependencies
  42. 42. OSGi Modularity Functionality (4/7) Sophisticated class space consistency model In addition to dependency resolution Exporters may declare package “uses” dependencies Exported packages express dependencies on imported or other exported packages, which constrain the resolve process The framework must ensure that importers do not violate constraints implied by “uses” dependencies Export-Package: foo Export-Package: foo A foo foo D
  43. 43. OSGi Modularity Functionality (4/7) Sophisticated class space consistency model In addition to dependency resolution Exporters may declare package “uses” dependencies Exported packages express dependencies on imported or other exported packages, which constrain the resolve process The framework must ensure that importers do not violate constraints implied by “uses” dependencies Import-Package: foo, bar A foo bar C foo foo D
  44. 44. OSGi Modularity Functionality (4/7) Sophisticated class space consistency model In addition to dependency resolution Exporters may declare package “uses” dependencies Exported packages express dependencies on imported or other exported packages, which constrain the resolve process The framework must ensure that importers do not violate constraints implied by “uses” dependencies Import-Package: foo Export-Package: bar; uses:=quot;fooquot; A foo foo B bar bar C foo foo D
  45. 45. OSGi Modularity Functionality (4/7) Sophisticated class space consistency model In addition to dependency resolution Exporters may declare package “uses” dependencies Exported packages express dependencies on imported or other exported packages, which constrain the resolve process The framework must ensure that importers do not violate constraints implied by “uses” dependencies Import-Package: foo Export-Package: bar; uses:=quot;fooquot; A foo foo B bar bar C foo foo D
  46. 46. OSGi Modularity Functionality (4/7) Sophisticated class space consistency model In addition to dependency resolution Exporters may declare package “uses” dependencies Exported packages express dependencies on imported or other exported packages, which constrain the resolve process The framework must ensure that importers do not violate constraints implied by “uses” dependencies Import-Package: foo Export-Package: bar; uses:=quot;fooquot; A foo foo B bar bar C foo foo D
  47. 47. OSGi Modularity Functionality (4/7) Sophisticated class space consistency model In addition to dependency resolution Exporters may declare package “uses” dependencies Exported packages express dependencies on imported or other exported packages, which constrain the resolve process The framework must ensure that importers do not violate constraints implied by “uses” dependencies Import-Package: foo Export-Package: bar; uses:=quot;fooquot; A foo foo B bar bar C foo foo D
  48. 48. OSGi Modularity Functionality (4/7) Sophisticated class space consistency model In addition to dependency resolution Exporters may declare package “uses” dependencies Exported packages express dependencies on imported or other exported packages, which constrain the resolve process The framework must ensure that importers do not violate constraints implied by “uses” dependencies Import-Package: foo Export-Package: bar; uses:=quot;fooquot; A foo foo B bar bar C foo foo D
  49. 49. OSGi Modularity Functionality (5/7) Package filtering for fine-grained class visibility Exporters may declare that certain classes are included/ excluded from the exported package
  50. 50. OSGi Modularity Functionality (5/7) Package filtering for fine-grained class visibility Exporters may declare that certain classes are included/ excluded from the exported package Export-Package: foo; exclude:=quot;*Implquot;, foo; friend=quot;yesquot;; mandatory:=quot;friendquot; A foo foo (exclude:=”*Impl”) friend=“yes” (include:=”*”)
  51. 51. OSGi Modularity Functionality (5/7) Package filtering for fine-grained class visibility Exporters may declare that certain classes are included/ excluded from the exported package Import-Package: foo Import-Package: foo; friend=quot;yesquot; B foo A foo C foo foo (exclude:=“*Impl”) friend=“yes” (include:=”*”)
  52. 52. OSGi Modularity Functionality (5/7) Package filtering for fine-grained class visibility Exporters may declare that certain classes are included/ excluded from the exported package Import-Package: foo Import-Package: foo; friend=quot;yesquot; B foo A foo C foo foo (exclude:=”*Impl”) friend=“yes” (include:=”*”)
  53. 53. OSGi Modularity Functionality (5/7) Package filtering for fine-grained class visibility Exporters may declare that certain classes are included/ excluded from the exported package Import-Package: foo Import-Package: foo; friend=“yes” B foo A foo C foo foo (exclude:=”*Impl”) friend=“yes” (include:=”*”)
  54. 54. OSGi Modularity Functionality (6/7) Bundle fragments Allows bundle content to be extended A special bundle that attaches to a host bundle and uses the same class loader Conceptually becomes part of the host bundle, allowing a logical bundle to be delivered in multiple physical bundles
  55. 55. OSGi Modularity Functionality (6/7) Bundle fragments Allows bundle content to be extended A special bundle that attaches to a host bundle and uses the same class loader Conceptually becomes part of the host bundle, allowing a logical bundle to be delivered in multiple physical bundles Fragment-Host: B Bundle-SymbolicName: B Export-Package: foo Export-Package: bar Import-Package: baz Import-Package: woz baz A foo woz B bar
  56. 56. OSGi Modularity Functionality (6/7) Bundle fragments Allows bundle content to be extended A special bundle that attaches to a host bundle and uses the same class loader Conceptually becomes part of the host bundle, allowing a logical bundle to be delivered in multiple physical bundles woz B bar baz A foo
  57. 57. OSGi Modularity Functionality (6/7) Bundle fragments Allows bundle content to be extended A special bundle that attaches to a host bundle and uses the same class loader Conceptually becomes part of the host bundle, allowing a logical bundle to be delivered in multiple physical bundles woz B bar baz A foo
  58. 58. OSGi Modularity Functionality (6/7) Bundle fragments Allows bundle content to be extended A special bundle that attaches to a host bundle and uses the same class loader Conceptually becomes part of the host bundle, allowing a logical bundle to be delivered in multiple physical bundles woz B bar baz A foo
  59. 59. OSGi Modularity Functionality (6/7) Bundle fragments Allows bundle content to be extended A special bundle that attaches to a host bundle and uses the same class loader Conceptually becomes part of the host bundle, allowing a logical bundle to be delivered in multiple physical bundles baz foo woz B bar baz A foo
  60. 60. OSGi Modularity Functionality (7/7) Bundle dependencies Allows for tight coupling of bundles when required Import everything that another, specific bundle exports Allows re-exporting and split packages
  61. 61. OSGi Modularity Functionality (7/7) Bundle dependencies Allows for tight coupling of bundles when required Import everything that another, specific bundle exports Allows re-exporting and split packages Bundle-SymbolicName: A Require-Bundle: A Export-Package: bar, foo Export-Package: bar bar A foo B bar
  62. 62. OSGi Modularity Functionality (7/7) Bundle dependencies Allows for tight coupling of bundles when required Import everything that another, specific bundle exports Allows re-exporting and split packages Bundle-SymbolicName: A Require-Bundle: A Export-Package: bar, foo Export-Package: bar bar A foo B bar
  63. 63. OSGi Run-time Class Search Order load class or find resource belongs to a java.* no belongs to an no belongs to a package no exported by a package? imported package? required bundle? yes yes yes delegate to delegate to delegate to exporters’ search local parent class loader exporter’s class loader class loaders class path no no yes no found? found? found? found? yes yes yes no lookup lookup failed succeeded
  64. 64. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86 Import-Package: osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; resolution:=quot;optionalquot; Export-Package: org.foo.service; version=1.1; vendor=quot;org.foo:quot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  65. 65. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Indicates R4 Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: and syntax semantics libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86 Import-Package: osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; resolution:=quot;optionalquot; Export-Package: org.foo.service; version=1.1; vendor=quot;org.fooquot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  66. 66. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: libfoo.so; osname=Linux; R4 ID Indicates processor=x86, Globally unique semantics and syntax foo.dll; osname=Windows 98; processor=x86 Import-Package: osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; resolution:=quot;optionalquot; Export-Package: org.foo.service; version=1.1; vendor=quot;org.fooquot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  67. 67. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: libfoo.so; Life cycle entry point osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86 Import-Package: osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; resolution:=quot;optionalquot; Export-Package: org.foo.service; version=1.1; vendor=quot;org.fooquot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  68. 68. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86 Internal bundle class path Import-Package: osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; resolution:=quot;optionalquot; Export-Package: org.foo.service; version=1.1; vendor=quot;org.fooquot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  69. 69. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86 Import-Package: osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; resolution:=quot;optionalquot; Native code dependencies Export-Package: org.foo.service; version=1.1; vendor=quot;org.fooquot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  70. 70. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: Optional dependency on a libfoo.so; osname=Linux; processor=x86, package version range foo.dll; osname=Windows 98; processor=x86 Import-Package: osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; resolution:=quot;optionalquot; Export-Package: org.foo.service; version=1.1; vendor=quot;org.fooquot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  71. 71. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86 Provided package with Import-Package: arbitrary attribute and excluded classes osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; resolution:=quot;optionalquot; Export-Package: org.foo.service; version=1.1; vendor=quot;org.fooquot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  72. 72. OSGi Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle Bundle-Version: 1.0.0 Bundle-Activator: org.foo.Activator Bundle-ClassPath: .,org/foo/embedded.jar Bundle-NativeCode: libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86 Import-Package: osgi.service.log; version=quot;[1.0.0,1.1.0)quot;; Provided package with resolution:=quot;optionalquot; dependency on exported Export-Package: package org.foo.service; version=1.1; vendor=quot;org.fooquot;; exclude:=quot;*Implquot;, org.foo.service.bar; version=1.1; uses:=quot;org.foo.servicequot;
  73. 73. OSGi Modularity Best Practices Partition public and non-public classes into separate packages Packages with public classes can be exported Non-public classes are not exported Use package imports rather than bundle dependencies Allows substitutability of package providers Limit fragment use Avoid use of dynamic imports Special type of optional import that is resolved at run time, instead of resolve time Intended for Class.forName() or SPI-like use cases
  74. 74. OSGi Modularity Tool Support Leveraging OSGi modularity Text editor + jar Just add metadata to your JAR file's manifest Eclipse Plug-in Development Environment directly supports bundles Bundle packaging tools BND from Peter Kriens Apache Felix Maven Bundle Plugin based on BND
  75. 75. OSGi as a Service- Oriented Application Framework
  76. 76. Service Orientation The OSGi framework promotes a service-oriented interaction pattern among bundles Service Registry Publish Find Service Description Service Service Provider Interact Requester
  77. 77. OSGi Applications A collection of bundles that interact via service interfaces Bundles may be independently developed and deployed Bundles and their associated services may appear or disappear at any time Resulting application follows a Service-Oriented Component Model approach Combines ideas from both component and service orientation
  78. 78. Bundle Life Cycle (Revisited) install INSTALLED uninstall resolve update uninstall UNINSTALLED RESOLVED start STARTING STOPPING explicit stop automatic ACTIVE
  79. 79. Bundle Life Cycle (Revisited) install Activating a bundle allows it INSTALLED to provide and use services uninstall resolve update uninstall UNINSTALLED RESOLVED start STARTING STOPPING explicit stop automatic ACTIVE
  80. 80. Bundle Activation Bundles can hook into their life cycle by implementing a bundle activator Notifies them when they are started/stopped Gives them access to their bundle context Which is how they access framework capabilities, e.g., Bundle life cycle management Publishing or looking up services
  81. 81. Bundle Activation Bundles can hook into their life cycle by implementing a bundle activator Notifies them when they are started/stopped Gives them access to their bundle context Which is how they access framework capabilities. e.g., Bundle life cycle management Publishing or looking up services Just a simple Java interface public interface BundleActivator { public void start(BundleContext context) throws Exception; public void stop(BundleContext context) throws Exception; }
  82. 82. Service Provision Illustration Conceptually, a bundle contains a single component which is the bundle activator Provided service Provided package existing bundle component OSGi framework
  83. 83. Service Provision Illustration Conceptually, a bundle contains a single component which is the bundle activator existing bundle install component bundle.jar OSGi framework
  84. 84. Service Provision Illustration Conceptually, a bundle contains a single component which is the bundle activator existing activate bundle bundle component OSGi framework
  85. 85. Service Provision Illustration Conceptually, a bundle contains a single component which is the bundle activator automatic package dependency resolution existing bundle component OSGi framework
  86. 86. Service Provision Illustration Conceptually, a bundle contains a single component which is the bundle activator manual service dependency resolution existing bundle component OSGi framework
  87. 87. Service-Oriented Applications Moving beyond the bundle activator as a component... Bundles can be seen as deployment units for component types These component types can be automatically instantiated, resolved, and managed dynamically at run time
  88. 88. Service-Oriented Applications Moving beyond the bundle activator as a component... Bundles can be seen as deployment units for component types These component types can be automatically instantiated, resolved, and managed dynamically at run time This view adopts a more general service-oriented component model approach Not directly supported by OSGi, but is enabled by it Goal is to enable a more POJO-based approach to creating OSGi applications i.e., the application code does not directly depend on OSGi API
  89. 89. Service-Oriented Application Illustration Bundles contained component types to be instantiated and managed existing bundle install component bundle.jar OSGi framework
  90. 90. Service-Oriented Application Illustration Bundles contained component types to be instantiated and managed existing activate bundle bundle component OSGi framework
  91. 91. Service-Oriented Application Illustration Bundles contained component types to be instantiated and managed existing bundle automatic package component dependency resolution OSGi framework
  92. 92. Service-Oriented Application Illustration Bundles contained component types to be instantiated and managed instantiate components existing bundle component OSGi framework
  93. 93. Service-Oriented Application Illustration Bundles contained component types to be instantiated and managed automatic service dependency resolution and maintenance with DS, Spring-DM, or iPOJO existing bundle component OSGi framework
  94. 94. Service-Oriented Application Advantages Lightweight services Direct method invocation Structured code Promotes separation of interface from implementation Enables reuse, substitutability, loose coupling, and late binding Dynamics Loose coupling and late binding make it possible to support run-time management of modules Application's architectural configuration is defined by the set of deployed bundles Just deploy the bundles that you need
  95. 95. Service-Oriented Application Issues Complicated Requires a different way of thinking Things you need might not be there or go away at any moment Must manually resolve service dependencies Must track and manage service dynamics There is help Service Tracker Still somewhat of a manual approach Old-fashioned approach Declarative Services (DS), Spring-OSGi, iPOJO Sophisticated service-oriented component frameworks Automated dependency injection More modern, POJO-oriented approaches
  96. 96. Declarative Services Example (1/2) Declarative Services provides a minimally intrusive way to Define components that provide and use services Automate dependency resolution and maintenance package foo.impl; public class HelloImpl implements foo.HelloService { LogService log; protected void setLog(LogService l) { log = l; } protected void unsetLog(LogService l) { log = null; } public void sayHello(String s) { log.log(LogService.LOG_INFO, quot;Hello quot; + s); } }
  97. 97. Declarative Services Example (2/2) Declarative Services component metadata <?xml version=quot;1.0quot; encoding=quot;UTF-8quot;?> <component name=quot;example.helloquot;> <implementation class=quot;foo.impl.HelloImplquot;/> <service> <provide interface=quot;foo.HelloServicequot;/> </service> <reference name=quot;LOGquot; interface=quot;org.osgi.service.log.LogServicequot; bind=quot;setLogquot; unbind=quot;unsetLogquot; /> </component>
  98. 98. iPOJO Example (1/2) iPOJO provides an extensible POJO-based way to An Apache Felix sub-project Defines components that provide and use services Automates dependency resolution and maintenance Defines composite components with sub-service visibility scoping Uses byte-code manipulation to simplify OSGi programming model
  99. 99. iPOJO Example (2/2) iPOJO simplifies metadata via byte-code reflection package foo.impl; @Component @Provides public class HelloImpl implements foo.HelloService { @Requires LogService log; public void sayHello(String s) { log.log(LogService.LOG_INFO, quot;Hello quot; + s); } }
  100. 100. OSGi Application Development Approach Modules vs. “Modules + Services” It is possible to use only the modularity aspects of the OSGi framework and not use services as a way of structuring your application May be necessary if another component model is already in use or application interaction is structured differently
  101. 101. OSGi Application Development Approach Modules vs. “Modules + Services” It is possible to use only the modularity aspects of the OSGi framework and not use services as a way of structuring your application May be necessary if another component model is already in use or application interaction is structured differently Bundled vs. Hosted An application can be a set of collaborating bundles that can be deployed on any framework or An application can host an embedded instance of the framework to create an extensibility/plugin mechanism Often ties the application to a specific framework implementation
  102. 102. Apache Felix Advertisement
  103. 103. Apache Felix (1/3) Top-level Apache project Apache licensed OSGi implementation Framework Version 1.0.4 currently available Completely stable and functional, but not all specification features implemented yet New 1.2.0 version expected soon Services Package Admin, Start Level, URL Handlers, Declarative Services, UPnP Device, HTTP Service, Configuration Admin, Preferences, User Admin, Wire Admin, Event Admin, Meta Type, and Log OSGi Bundle Repository (OBR), Dependency Manager, Service Binder, Shell (TUI and GUI), iPOJO, Mangen
  104. 104. Apache Felix (2/3) Strong community Several regular committers and many regular contributors Very responsive community Code granted and contributed from several organizations and communities Grenoble University, ObjectWeb, CNR-ISTI, Ascert, Luminis, Apache Directory, INSA, DIT UPM, Day Management AG, Jayway Several community member contributions
  105. 105. Apache Felix (3/3) Apache Maven Bundle Plugin Merges OSGi bundle manifest with Maven2 POM file Automatically generates metadata, such as Bundle- ClassPath, Import-Package, and Export-Package Greatly simplifies bundle development by eliminating error- prone manual header creation process Automatically creates final bundle JAR file Also supports embed required packages, instead of importing them
  106. 106. Conclusions
  107. 107. Conclusions Java needs improved modularity support Lagging behind .NET in this area for years The OSGi framework provides it now And has a proven track record for many years Importance and relevance of OSGi is growing Industry support for mobile applications Significant uptake in the enterprise space Work underway on R4.2 specification that will show the fruit of Java EE focus
  108. 108. Questions?

×