OSGi R4 Framework Improves Java Modularity with Flexible Package Dependencies

New Modularity Features of
the OSGi R4 Service
Platform
Richard S. HallRichard S. Hall

Motivation
Improving Upon Success

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...

•• ““(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?

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

Java & OSGi R3
Modularity Support & Limitations

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

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

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

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

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

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

OSGi R4 Framework
Modularity Support for the Future

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

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

OSGi R4 Modularity (1)OSGi R4 Modularity (1)
•• Limitation: Package sharing is only globalLimitation: Package sharing is only global

•• 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

•• 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)”

•• Limitation: Not intended for sharing implementationLimitation: Not intended for sharing implementation
packagespackages

•• Limitation: Not intended for sharing implementationLimitation: Not intended for sharing implementation
packagespackages
• Multi-version sharing and importing version ranges
make implementation package sharing possible

•• 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”
version=“1.0.0”
A
foo
(myattr=“myvalue”) Bfoo

A
foo
(myattr=myvalue) BfooCfoo
Import-Package: foo;

A
foo
(myattr=myvalue)
Cfoo Bfoo

•• 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

DfooA foo C foobar
Import-Package: foo, bar

DfooA foo B barfoo
Import-Package: foo
Export-Package: bar;
uses:=“foo”
C foobar

DfooA foo C foobarB barfoo
Import-Package: foo
Export-Package: bar;
uses:=“foo”

•• 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
exclude:=“*Impl”,
foo; friend=“yes”;
mandatory:=“friend”

foo
(exclude:=“*Impl”)
A CfooB foo
friend=“yes”
Import-Package: foo
foo
friend=“yes”
(include:=”*”)

A
Import-Package: foo
CfooB foo
foo
friend=“yes”
(include:=”*”)
foo
(exclude:=”*Impl”)
friend=“yes”

•• 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

fooAbaz
barBwoz

barBwoz
fooAbaz

bar
foo
B
fooAbaz
woz
baz

•• 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

foo
bar
A
Require-Bundle: A
Export-Package: bar
Bundle-SymbolicName: A
Export-Package: bar, foo
B bar

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”

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

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

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

OSGi R4 Framework Improves Java Modularity with Flexible Package Dependencies

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à OSGi R4 Framework Improves Java Modularity with Flexible Package Dependencies

Similaire à OSGi R4 Framework Improves Java Modularity with Flexible Package Dependencies (20)

Plus de mfrancis

Plus de mfrancis (20)

Dernier

Dernier (20)

OSGi R4 Framework Improves Java Modularity with Flexible Package Dependencies