Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

New Modularity Features of the OSGi R4 Service Platform - Richard Hall, Ph.D., Invited Researcher, University of Grenoble

285 views

Published on

OSGi World Congress 2005 - Developer Forum Day 1

Published in: Technology
  • Be the first to comment

  • Be the first to like this

New Modularity Features of the OSGi R4 Service Platform - Richard Hall, Ph.D., Invited Researcher, University of Grenoble

  1. 1. New Modularity Features of the OSGi R4 Service Platform Richard S. HallRichard S. Hall
  2. 2. Motivation Improving Upon Success
  3. 3. OSGi Success as a Modularity FrameworkOSGi Success as a Modularity Framework •• OSGi framework is increasingly used as aOSGi framework is increasingly used as a modularity mechanism for Javamodularity mechanism for Java –– Provides logical and physical system structuringProvides logical and physical system structuring •• Has benefits for development and deploymentHas benefits for development and deployment –– Provides sophisticated dynamic module lifeProvides sophisticated dynamic module life--cyclecycle managementmanagement •• Simplifies creation of dynamicallySimplifies creation of dynamically extensible systemsextensible systems –– Where system components can be added, removed, or rebound at runWhere system components can be added, removed, or rebound at run time while the system as a whole continues to functiontime while the system as a whole continues to function •• However, modularity was not the original goal...However, modularity was not the original goal...
  4. 4. •• ““(Desirable) property of a system, such that(Desirable) property of a system, such that individual components can be examined, modifiedindividual components can be examined, modified and maintained independently of the remainder ofand maintained independently of the remainder of the system. Objective is that changes in one part ofthe system. Objective is that changes in one part of a system should not lead to unexpected behavior ina system should not lead to unexpected behavior in other parts.other parts.”” (www.maths.bath.ac.uk/~jap/MATH0015/glossary.html)(www.maths.bath.ac.uk/~jap/MATH0015/glossary.html) •• Different types of modularityDifferent types of modularity –– LogicalLogical •• Useful during development to decompose and/or structure theUseful during development to decompose and/or structure the systemsystem –– PhysicalPhysical •• Useful after development to simplify deploymentUseful after development to simplify deployment and maintenanceand maintenance What is Modularity?What is Modularity?
  5. 5. Why Care About Modularity?Why Care About Modularity? •• Simplifies the creation of large, complex systemsSimplifies the creation of large, complex systems –– Improves robustnessImproves robustness –– Eases problem diagnosisEases problem diagnosis –– Enables splitting work among independent teamsEnables splitting work among independent teams •• Simplifies the deployment and maintenance ofSimplifies the deployment and maintenance of systemssystems •• Simplifies aspects of extensible and dynamicSimplifies aspects of extensible and dynamic systemssystems •• Java needs improvement in this areaJava needs improvement in this area –– Java currently lags .NET in support for modularityJava currently lags .NET in support for modularity –– OSGi specification deals with many of theseOSGi specification deals with many of these issues and can fill that gapissues and can fill that gap
  6. 6. Java & OSGi R3 Modularity Support & Limitations
  7. 7. Standard Java Modularity MechanismsStandard Java Modularity Mechanisms •• ClassesClasses –– Provide logical static scoping via access modifiers (i.e.,Provide logical static scoping via access modifiers (i.e., publicpublic,, protectedprotected,, privateprivate)) •• PackagesPackages –– Provide logical static scoping viaProvide logical static scoping via package privatespackage privates –– Namespace mechanism, avoids name clashesNamespace mechanism, avoids name clashes •• Java Archive (JAR) filesJava Archive (JAR) files –– Provide form of physical modularityProvide form of physical modularity •• May contain applications, extensions, or servicesMay contain applications, extensions, or services •• May declare dependenciesMay declare dependencies •• May contain package version and sealing informationMay contain package version and sealing information •• Class loadersClass loaders –– Enable runEnable run--time code loadingtime code loading –– Provide logical dynamic scopingProvide logical dynamic scoping
  8. 8. Standard Java Modularity Limitations (1)Standard Java Modularity Limitations (1) •• Limited scoping mechanismsLimited scoping mechanisms –– No module access modifierNo module access modifier •• Simplistic version handlingSimplistic version handling –– Class path is first version foundClass path is first version found –– JAR files assume backwards compatibility at bestJAR files assume backwards compatibility at best •• Implicit dependenciesImplicit dependencies –– Dependencies are implicit in class path orderingDependencies are implicit in class path ordering –– JAR files add improvements for extensions, but cannotJAR files add improvements for extensions, but cannot control visibilitycontrol visibility •• Split packages by defaultSplit packages by default –– Class path approach searches until if finds, which canClass path approach searches until if finds, which can lead to shadowing or mixing of versionslead to shadowing or mixing of versions –– JAR files can provide sealingJAR files can provide sealing
  9. 9. Standard Java Modularity Limitations (2)Standard Java Modularity Limitations (2) •• LowLow--level support for dynamicslevel support for dynamics –– Class loaders are complicated to useClass loaders are complicated to use •• Unsophisticated consistency modelUnsophisticated consistency model –– Cuts across previous issues, it is difficult to ensure classCuts across previous issues, it is difficult to ensure class space consistencyspace consistency •• Missing module conceptMissing module concept –– Classes too fine grained, packages too simplistic, classClasses too fine grained, packages too simplistic, class loaders too low levelloaders too low level –– JAR files are best candidates, but still inadequateJAR files are best candidates, but still inadequate –– Modularity is a secondModularity is a second--class concept as opposed to theclass concept as opposed to the .NET platform.NET platform •• In .NET, Assembly usage is enforced with explicitIn .NET, Assembly usage is enforced with explicit versioning rules and sharing occurs via the Globalversioning rules and sharing occurs via the Global Assembly CacheAssembly Cache
  10. 10. OSGi R3 ModularityOSGi R3 Modularity •• Improves upon standard Java modularityImproves upon standard Java modularity –– DefinesDefines bundlebundle, a logical and physical modularity unit, a logical and physical modularity unit •• Explicit dependenciesExplicit dependencies •• Explicit versioningExplicit versioning •• Internal class path conceptInternal class path concept •• Code isolationCode isolation •• Packaging formatPackaging format –– Defines dynamic bundle life cycleDefines dynamic bundle life cycle •• Possible to install, update, and uninstall code at run timePossible to install, update, and uninstall code at run time •• Replaces lowReplaces low--level class loaderslevel class loaders
  11. 11. OSGi R3 Modularity Issues (1)OSGi R3 Modularity Issues (1) •• Package sharing is only globalPackage sharing is only global –– Cannot have multiple shared versionsCannot have multiple shared versions •• Simplistic versioning semanticsSimplistic versioning semantics –– Always backwards compatibleAlways backwards compatible •• Not intended for sharing implementation packagesNot intended for sharing implementation packages –– Only for specification packages, which was why theOnly for specification packages, which was why the version model is simpleversion model is simple •• Provider selection is always anonymousProvider selection is always anonymous –– No way to influence selectionNo way to influence selection
  12. 12. OSGi R3 Modularity Issues (2)OSGi R3 Modularity Issues (2) •• Simplistic consistency modelSimplistic consistency model –– Consistency model based on single inConsistency model based on single in--use versionuse version –– No way to declare dependencies among packagesNo way to declare dependencies among packages •• CoarseCoarse--grained package visibility rulesgrained package visibility rules –– Classes in a package are either completely visible toClasses in a package are either completely visible to everyone or hiddeneveryone or hidden •• Module content is not extensibleModule content is not extensible –– All content of the logical module must be included in theAll content of the logical module must be included in the physical modulephysical module •• Package dependencies are not always appropriatePackage dependencies are not always appropriate –– Package metadata is cumbersome in large,Package metadata is cumbersome in large, complex systems, tightly coupled subsystemscomplex systems, tightly coupled subsystems and in less structured legacy systemsand in less structured legacy systems
  13. 13. OSGi R4 Framework Modularity Support for the Future
  14. 14. Modularity RequirementsModularity Requirements •• Backwards compatible with OSGi R3Backwards compatible with OSGi R3 •• Defined in terms of Java packagesDefined in terms of Java packages –– WellWell--defined concept in Javadefined concept in Java –– Maps nicely to class loadersMaps nicely to class loaders •• Explicitly defined boundariesExplicitly defined boundaries •• Explicitly defined dependenciesExplicitly defined dependencies •• Support for versioning and multiSupport for versioning and multi--versionsversions •• Flexible, must supportFlexible, must support –– Small to large systemsSmall to large systems –– Static to dynamic systemsStatic to dynamic systems
  15. 15. Related WorkRelated Work •• Module mechanismsModule mechanisms –– MJ: A Rational Module System for Java and itsMJ: A Rational Module System for Java and its Applications (J. Corwin et alApplications (J. Corwin et al –– IBM)IBM) –– Mechanisms for Secure Modular Programming in JavaMechanisms for Secure Modular Programming in Java (L. Bauer et al(L. Bauer et al –– Princeton University)Princeton University) –– Units: Cool Modules for HOT Languages (M. Flatt andUnits: Cool Modules for HOT Languages (M. Flatt and M. FelleisenM. Felleisen –– Rice University)Rice University) –– Evolving Software with Extensible Modules (M. ZengerEvolving Software with Extensible Modules (M. Zenger –– ÉÉcole Polytechnique Fcole Polytechnique Fééddéérale de Lausanne)rale de Lausanne) •• Component and extensible frameworksComponent and extensible frameworks –– EJB, Eclipse, NetBeansEJB, Eclipse, NetBeans •• Microsoft .NETMicrosoft .NET –– Assemblies and Global Assembly CacheAssemblies and Global Assembly Cache
  16. 16. OSGi R4 Modularity (1)OSGi R4 Modularity (1) •• Limitation: Package sharing is only globalLimitation: Package sharing is only global
  17. 17. OSGi R4 Modularity (1)OSGi R4 Modularity (1) •• Limitation: Package sharing is only globalLimitation: Package sharing is only global •• MultiMulti--version supportversion support –– Possible to have more than one version of a sharedPossible to have more than one version of a shared package in memory at the same timepackage in memory at the same time –– General change of philosophy to the prior OSGiGeneral change of philosophy to the prior OSGi specificationsspecifications –– Has deep impact on service aspects as well asHas deep impact on service aspects as well as modularitymodularity •• For a given bundle, the service registry is implicitly partitionFor a given bundle, the service registry is implicitly partitioneded according to the package versions visible to itaccording to the package versions visible to it •• Impact on services not explored further in this presentationImpact on services not explored further in this presentation
  18. 18. OSGi R4 Modularity (2)OSGi R4 Modularity (2) •• Limitation: Simplistic versioning semanticsLimitation: Simplistic versioning semantics
  19. 19. OSGi R4 Modularity (2)OSGi R4 Modularity (2) •• Limitation: Simplistic versioning semanticsLimitation: Simplistic versioning semantics •• Import version rangesImport version ranges –– Exporters still export a precise version, but importersExporters still export a precise version, but importers may specify an open or closed version rangemay specify an open or closed version range –– Eliminates existing backwards compatibility assumptionEliminates existing backwards compatibility assumption
  20. 20. OSGi R4 Modularity (2)OSGi R4 Modularity (2) •• Limitation: Simplistic versioning semanticsLimitation: Simplistic versioning semantics •• Import version rangesImport version ranges –– Exporters still export a precise version, but importersExporters still export a precise version, but importers may specify an open or closed version rangemay specify an open or closed version range –– Eliminates existing backwards compatibility assumptionEliminates existing backwards compatibility assumption Import-Package: foo; version=“[1.0.0,1.5.0)”
  21. 21. OSGi R4 Modularity (2)OSGi R4 Modularity (2) •• Limitation: Simplistic versioning semanticsLimitation: Simplistic versioning semantics •• Import version rangesImport version ranges –– Exporters still export a precise version, but importersExporters still export a precise version, but importers may specify an open or closed version rangemay specify an open or closed version range –– Eliminates existing backwards compatibility assumptionEliminates existing backwards compatibility assumption •• Limitation: Not intended for sharing implementationLimitation: Not intended for sharing implementation packagespackages Import-Package: foo; version=“[1.0.0,1.5.0)”
  22. 22. OSGi R4 Modularity (2)OSGi R4 Modularity (2) •• Limitation: Simplistic versioning semanticsLimitation: Simplistic versioning semantics •• Import version rangesImport version ranges –– Exporters still export a precise version, but importersExporters still export a precise version, but importers may specify an open or closed version rangemay specify an open or closed version range –– Eliminates existing backwards compatibility assumptionEliminates existing backwards compatibility assumption •• Limitation: Not intended for sharing implementationLimitation: Not intended for sharing implementation packagespackages • Multi-version sharing and importing version ranges make implementation package sharing possible Import-Package: foo; version=“[1.0.0,1.5.0)”
  23. 23. OSGi R4 Modularity (3)OSGi R4 Modularity (3) •• Limitation: Provider selection is always anonymousLimitation: Provider selection is always anonymous
  24. 24. OSGi R4 Modularity (3)OSGi R4 Modularity (3) •• Limitation: Provider selection is always anonymousLimitation: Provider selection is always anonymous •• Arbitrary export/import attributesArbitrary export/import attributes –– Exporters may attach arbitrary attributes to their exports,Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributesimporters can match against these arbitrary attributes •• Exporters may declare attributes as mandatoryExporters may declare attributes as mandatory –– Mandatory attributes provide simple means to limit package visibMandatory attributes provide simple means to limit package visibilityility –– Importers influence package selection using arbitraryImporters influence package selection using arbitrary attribute matchingattribute matching
  25. 25. OSGi R4 Modularity (3)OSGi R4 Modularity (3) •• Limitation: Provider selection is always anonymousLimitation: Provider selection is always anonymous •• Arbitrary export/import attributesArbitrary export/import attributes –– Exporters may attach arbitrary attributes to their exports,Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributesimporters can match against these arbitrary attributes •• Exporters may declare attributes as mandatoryExporters may declare attributes as mandatory –– Mandatory attributes provide simple means to limit package visibMandatory attributes provide simple means to limit package visibilityility –– Importers influence package selection using arbitraryImporters influence package selection using arbitrary attribute matchingattribute matching Export-Package: foo; version=“1.0.0”; myattr=“myvalue” Export-Package: foo; version=“1.0.0” A foo (myattr=“myvalue”) Bfoo
  26. 26. OSGi R4 Modularity (3)OSGi R4 Modularity (3) •• Limitation: Provider selection is always anonymousLimitation: Provider selection is always anonymous •• Arbitrary export/import attributesArbitrary export/import attributes –– Exporters may attach arbitrary attributes to their exports,Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributesimporters can match against these arbitrary attributes •• Exporters may declare attributes as mandatoryExporters may declare attributes as mandatory –– Mandatory attributes provide simple means to limit package visibMandatory attributes provide simple means to limit package visibilityility –– Importers influence package selection using arbitraryImporters influence package selection using arbitrary attribute matchingattribute matching A foo (myattr=myvalue) BfooCfoo Import-Package: foo; version=“1.0.0”; myattr=“myvalue”
  27. 27. OSGi R4 Modularity (3)OSGi R4 Modularity (3) •• Limitation: Provider selection is always anonymousLimitation: Provider selection is always anonymous •• Arbitrary export/import attributesArbitrary export/import attributes –– Exporters may attach arbitrary attributes to their exports,Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributesimporters can match against these arbitrary attributes •• Exporters may declare attributes as mandatoryExporters may declare attributes as mandatory –– Mandatory attributes provide simple means to limit package visibMandatory attributes provide simple means to limit package visibilityility –– Importers influence package selection using arbitraryImporters influence package selection using arbitrary attribute matchingattribute matching A foo (myattr=myvalue) Import-Package: foo; version=“1.0.0”; myattr=“myvalue” Cfoo Bfoo
  28. 28. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model
  29. 29. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model •• Sophisticated package consistency modelSophisticated package consistency model –– Exporters may declare packageExporters may declare package ““usesuses”” dependenciesdependencies •• Exported packages express dependencies on imported orExported packages express dependencies on imported or other exported packages, which constrain the resolve processother exported packages, which constrain the resolve process –– The framework must ensure that importers do not violateThe framework must ensure that importers do not violate constraints implied byconstraints implied by ““usesuses”” dependenciesdependencies
  30. 30. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model •• Sophisticated package consistency modelSophisticated package consistency model –– Exporters may declare packageExporters may declare package ““usesuses”” dependenciesdependencies •• Exported packages express dependencies on imported orExported packages express dependencies on imported or other exported packages, which constrain the resolve processother exported packages, which constrain the resolve process –– The framework must ensure that importers do not violateThe framework must ensure that importers do not violate constraints implied byconstraints implied by ““usesuses”” dependenciesdependencies DfooA foo Export-Package: foo Export-Package: foo
  31. 31. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model •• Sophisticated package consistency modelSophisticated package consistency model –– Exporters may declare packageExporters may declare package ““usesuses”” dependenciesdependencies •• Exported packages express dependencies on imported orExported packages express dependencies on imported or other exported packages, which constrain the resolve processother exported packages, which constrain the resolve process –– The framework must ensure that importers do not violateThe framework must ensure that importers do not violate constraints implied byconstraints implied by ““usesuses”” dependenciesdependencies DfooA foo C foobar Import-Package: foo, bar
  32. 32. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model •• Sophisticated package consistency modelSophisticated package consistency model –– Exporters may declare packageExporters may declare package ““usesuses”” dependenciesdependencies •• Exported packages express dependencies on imported orExported packages express dependencies on imported or other exported packages, which constrain the resolve processother exported packages, which constrain the resolve process –– The framework must ensure that importers do not violateThe framework must ensure that importers do not violate constraints implied byconstraints implied by ““usesuses”” dependenciesdependencies DfooA foo B barfoo Import-Package: foo Export-Package: bar; uses:=“foo” C foobar
  33. 33. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model •• Sophisticated package consistency modelSophisticated package consistency model –– Exporters may declare packageExporters may declare package ““usesuses”” dependenciesdependencies •• Exported packages express dependencies on imported orExported packages express dependencies on imported or other exported packages, which constrain the resolve processother exported packages, which constrain the resolve process –– The framework must ensure that importers do not violateThe framework must ensure that importers do not violate constraints implied byconstraints implied by ““usesuses”” dependenciesdependencies DfooA foo C foobarB barfoo Import-Package: foo Export-Package: bar; uses:=“foo”
  34. 34. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model •• Sophisticated package consistency modelSophisticated package consistency model –– Exporters may declare packageExporters may declare package ““usesuses”” dependenciesdependencies •• Exported packages express dependencies on imported orExported packages express dependencies on imported or other exported packages, which constrain the resolve processother exported packages, which constrain the resolve process –– The framework must ensure that importers do not violateThe framework must ensure that importers do not violate constraints implied byconstraints implied by ““usesuses”” dependenciesdependencies DfooA foo C foobarB barfoo Import-Package: foo Export-Package: bar; uses:=“foo”
  35. 35. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model •• Sophisticated package consistency modelSophisticated package consistency model –– Exporters may declare packageExporters may declare package ““usesuses”” dependenciesdependencies •• Exported packages express dependencies on imported orExported packages express dependencies on imported or other exported packages, which constrain the resolve processother exported packages, which constrain the resolve process –– The framework must ensure that importers do not violateThe framework must ensure that importers do not violate constraints implied byconstraints implied by ““usesuses”” dependenciesdependencies DfooA foo C foobarB barfoo Import-Package: foo Export-Package: bar; uses:=“foo”
  36. 36. OSGi R4 Modularity (4)OSGi R4 Modularity (4) •• Limitation: Simplistic consistency modelLimitation: Simplistic consistency model •• Sophisticated package consistency modelSophisticated package consistency model –– Exporters may declare packageExporters may declare package ““usesuses”” dependenciesdependencies •• Exported packages express dependencies on imported orExported packages express dependencies on imported or other exported packages, which constrain the resolve processother exported packages, which constrain the resolve process –– The framework must ensure that importers do not violateThe framework must ensure that importers do not violate constraints implied byconstraints implied by ““usesuses”” dependenciesdependencies DfooA foo C foobarB barfoo Import-Package: foo Export-Package: bar; uses:=“foo”
  37. 37. OSGi R4 Modularity (5)OSGi R4 Modularity (5) •• Limitation: CoarseLimitation: Coarse--grained package visibility rulesgrained package visibility rules
  38. 38. OSGi R4 Modularity (5)OSGi R4 Modularity (5) •• Limitation: CoarseLimitation: Coarse--grained package visibility rulesgrained package visibility rules •• Package filteringPackage filtering –– Exporters may declare that certain classes areExporters may declare that certain classes are included/excluded from the exported packageincluded/excluded from the exported package
  39. 39. OSGi R4 Modularity (5)OSGi R4 Modularity (5) •• Limitation: CoarseLimitation: Coarse--grained package visibility rulesgrained package visibility rules •• Package filteringPackage filtering –– Exporters may declare that certain classes areExporters may declare that certain classes are included/excluded from the exported packageincluded/excluded from the exported package foo friend=“yes” (include:=”*”) foo (exclude:=”*Impl”) A Export-Package: foo; exclude:=“*Impl”, foo; friend=“yes”; mandatory:=“friend”
  40. 40. OSGi R4 Modularity (5)OSGi R4 Modularity (5) •• Limitation: CoarseLimitation: Coarse--grained package visibility rulesgrained package visibility rules •• Package filteringPackage filtering –– Exporters may declare that certain classes areExporters may declare that certain classes are included/excluded from the exported packageincluded/excluded from the exported package foo (exclude:=“*Impl”) A CfooB foo Import-Package: foo; friend=“yes” Import-Package: foo foo friend=“yes” (include:=”*”)
  41. 41. OSGi R4 Modularity (5)OSGi R4 Modularity (5) •• Limitation: CoarseLimitation: Coarse--grained package visibility rulesgrained package visibility rules •• Package filteringPackage filtering –– Exporters may declare that certain classes areExporters may declare that certain classes are included/excluded from the exported packageincluded/excluded from the exported package A Import-Package: foo CfooB foo foo friend=“yes” (include:=”*”) foo (exclude:=”*Impl”) Import-Package: foo; friend=“yes”
  42. 42. OSGi R4 Modularity (5)OSGi R4 Modularity (5) •• Limitation: CoarseLimitation: Coarse--grained package visibility rulesgrained package visibility rules •• Package filteringPackage filtering –– Exporters may declare that certain classes areExporters may declare that certain classes are included/excluded from the exported packageincluded/excluded from the exported package A Import-Package: foo CfooB foo foo friend=“yes” (include:=”*”) foo (exclude:=”*Impl”) Import-Package: foo; friend=“yes”
  43. 43. OSGi R4 Modularity (6)OSGi R4 Modularity (6) •• Limitation: Module content is not extensibleLimitation: Module content is not extensible
  44. 44. OSGi R4 Modularity (6)OSGi R4 Modularity (6) •• Limitation: Module content is not extensibleLimitation: Module content is not extensible •• Bundle fragmentsBundle fragments –– A special bundle that attaches to a host bundle and usesA special bundle that attaches to a host bundle and uses the same class loaderthe same class loader •• Conceptually becomes part of the host bundleConceptually becomes part of the host bundle
  45. 45. OSGi R4 Modularity (6)OSGi R4 Modularity (6) •• Limitation: Module content is not extensibleLimitation: Module content is not extensible •• Bundle fragmentsBundle fragments –– A special bundle that attaches to a host bundle and usesA special bundle that attaches to a host bundle and uses the same class loaderthe same class loader •• Conceptually becomes part of the host bundleConceptually becomes part of the host bundle fooAbaz barBwoz Fragment-Host: B Export-Package: foo Import-Package: baz Bundle-SymbolicName: B Export-Package: bar Import-Package: woz
  46. 46. fooAbaz OSGi R4 Modularity (6)OSGi R4 Modularity (6) •• Limitation: Module content is not extensibleLimitation: Module content is not extensible •• Bundle fragmentsBundle fragments –– A special bundle that attaches to a host bundle and usesA special bundle that attaches to a host bundle and uses the same class loaderthe same class loader •• Conceptually becomes part of the host bundleConceptually becomes part of the host bundle barBwoz
  47. 47. OSGi R4 Modularity (6)OSGi R4 Modularity (6) •• Limitation: Module content is not extensibleLimitation: Module content is not extensible •• Bundle fragmentsBundle fragments –– A special bundle that attaches to a host bundle and usesA special bundle that attaches to a host bundle and uses the same class loaderthe same class loader •• Conceptually becomes part of the host bundleConceptually becomes part of the host bundle barBwoz fooAbaz
  48. 48. OSGi R4 Modularity (6)OSGi R4 Modularity (6) •• Limitation: Module content is not extensibleLimitation: Module content is not extensible •• Bundle fragmentsBundle fragments –– A special bundle that attaches to a host bundle and usesA special bundle that attaches to a host bundle and uses the same class loaderthe same class loader •• Conceptually becomes part of the host bundleConceptually becomes part of the host bundle barBwoz fooAbaz
  49. 49. OSGi R4 Modularity (6)OSGi R4 Modularity (6) •• Limitation: Module content is not extensibleLimitation: Module content is not extensible •• Bundle fragmentsBundle fragments –– A special bundle that attaches to a host bundle and usesA special bundle that attaches to a host bundle and uses the same class loaderthe same class loader •• Conceptually becomes part of the host bundleConceptually becomes part of the host bundle bar foo B fooAbaz woz baz
  50. 50. OSGi R4 Modularity (7)OSGi R4 Modularity (7) •• Limitation: Package dependencies are not alwaysLimitation: Package dependencies are not always appropriateappropriate
  51. 51. OSGi R4 Modularity (7)OSGi R4 Modularity (7) •• Limitation: Package dependencies are not alwaysLimitation: Package dependencies are not always appropriateappropriate •• Bundle dependenciesBundle dependencies –– Import everything that another, specific bundle exportsImport everything that another, specific bundle exports –– Allows reAllows re--exportingexporting
  52. 52. OSGi R4 Modularity (7)OSGi R4 Modularity (7) •• Limitation: Package dependencies are not alwaysLimitation: Package dependencies are not always appropriateappropriate •• Bundle dependenciesBundle dependencies –– Import everything that another, specific bundle exportsImport everything that another, specific bundle exports –– Allows reAllows re--exportingexporting B barfoo bar A Require-Bundle: A Export-Package: bar Bundle-SymbolicName: A Export-Package: bar, foo
  53. 53. OSGi R4 Modularity (7)OSGi R4 Modularity (7) •• Limitation: Package dependencies are not alwaysLimitation: Package dependencies are not always appropriateappropriate •• Bundle dependenciesBundle dependencies –– Import everything that another, specific bundle exportsImport everything that another, specific bundle exports –– Allows reAllows re--exportingexporting foo bar A Require-Bundle: A Export-Package: bar Bundle-SymbolicName: A Export-Package: bar, foo B bar
  54. 54. Example OSGi R4 Bundle ManifestExample OSGi R4 Bundle Manifest Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.simplebundle 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: javax.servlet; version=“[2.0.0,2.4.0)”; resolution:=“optional” Export-Package: org.foo.service; version=1.1; vendor=“org.foo”; exclude:=“*Impl”, org.foo.service.bar; version=1.1; uses:=“org.foo.service”
  55. 55. ChallengesChallenges •• Manage the complexityManage the complexity –– Maintain conceptual integrityMaintain conceptual integrity –– Keep the simple cases simpleKeep the simple cases simple –– Complexity should only be visible when it is requiredComplexity should only be visible when it is required –– Avoid bloat to support small devicesAvoid bloat to support small devices
  56. 56. ChallengesChallenges •• Manage the complexityManage the complexity –– Maintain conceptual integrityMaintain conceptual integrity –– Keep the simple cases simpleKeep the simple cases simple –– Complexity should only be visible when it is requiredComplexity should only be visible when it is required –– Avoid bloat to support small devicesAvoid bloat to support small devices TheThe ““good newsgood news”” is that these changes generallyis that these changes generally only affect the dependency resolving algorithmonly affect the dependency resolving algorithm
  57. 57. ConclusionsConclusions •• Java needs improved modularity supportJava needs improved modularity support –– We need to stop reWe need to stop re--inventing the wheelinventing the wheel –– Improve application structureImprove application structure –– Simplify deployment and management especially inSimplify deployment and management especially in technological areas where deployment is inherenttechnological areas where deployment is inherent •• e.g., component orientation, extensible systems, and servicee.g., component orientation, extensible systems, and service orientation (to some degree)orientation (to some degree) •• OSGi R1/R2/R3 were all steps in the right directionOSGi R1/R2/R3 were all steps in the right direction •• OSGi R4 goes even further in providingOSGi R4 goes even further in providing sophisticated Java modularitysophisticated Java modularity –– OSGi technology is cited in JSR 277, an initiative by SunOSGi technology is cited in JSR 277, an initiative by Sun to define a module system for Java, whose expert groupto define a module system for Java, whose expert group includes OSGi membersincludes OSGi members
  58. 58. Questions?

×