Managing Change
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Managing Change

  • 3,142 views
Uploaded on

Presentation at the OSGi DevCon 2009 in Zurich.

Presentation at the OSGi DevCon 2009 in Zurich.
Presenters:
Neil Bartlett
Mirko Jahn

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,142
On Slideshare
3,033
From Embeds
109
Number of Embeds
3

Actions

Shares
Downloads
46
Comments
0
Likes
2

Embeds 109

http://osgilook.wordpress.com 57
http://osgilook.com 44
http://www.slideshare.net 8

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Change as inevitable part of life and of course software development.
  • Well, you’ll never get bored.
  • Only solution is to embrace change and expect it! It will hunt you down otherwise!!! Where are we right now?  Let’s see what others are doing
  • “ Manifest” compiled into the assembly Versioning: Major.Minor.Build.Revision (no strings, only integers separated by dot) Assembly Binding -> Application Domain with all dependencies declared on a fixed version or no version at all(for development). Only version ranges known are redirects on machine + configuration file level ApplicationDomains as the only way to use different versions of the same dll, but then you have to use inter process communication Assembly cache is pretty much the same as a java class path (no multiple version support)
  • SOA in the JVM to better explain the importance of services. If no version is given, the default 0.0.0 is taken.
  • Introduce the use case scenario
  • The bundles can be downloaded for testing from github: http://github.com/mirkojahn/OSGiVersioningTutorial/downloads Simple API as the basis of the discussion. DictionaryService will be exposed as a service in this example and we will see, how the evolution of this API affect the runtime when deploying multiple versions simultaneously in a special order. Diagram: http://yuml.me/diagram/class/[Dictionary||+getLanguage();+check(String){bg:cornsilk}]0..*-0..*+[DictionaryService||+registerDictionary(Dictionary);+unregisterDictionary(Dictionary);+check(String){bg:cornsilk}]
  • Point out: Separation in API and impl (maybe just introduce that in version 1.1.0 and just import your exports?) Import your exports not necessary in this distinct case, because the API is provided separately. Console/Client bundle to show the output Point out the different version dependencies between consumer and implementer of the API: Implementation dependencies on minor User dependencies on major Workflow: resolve dictionary.api resolve dictionary.impl resolve cl.client start dictionary.impl (service gets published) start cl.client (consumes service (and publishes the console service))
  • Same API as before, but this time the DictionaryService got a new method to also take the language as an argument. Diagram: http://yuml.me/diagram/class/[Dictionary||+getLanguage();+check(String){bg:cornsilk}]0..*-0..*+[DictionaryService||+registerDictionary(Dictionary);+unregisterDictionary(Dictionary);+check(String);+check(String String){bg:cornsilk}]
  • Point out: Step one: new bundles are introduced Step two: the new impl. can theoretically be bound to the new and old api Step three: the new dictionary.impl bundle registers the service (and exposes either the old or the new API) Step four: The new cl.client can only resolve to the new API (it relies on the new method). Depending on the resolution, the client might be able to bind to the new service registered. Step five: after refresh packages the old client can bind to the new or old api (there is a difference on calling refreshPackages on all or just on the cl.client bundle!!! Try it to figure this out ;-)) Depending on what it is bound to it might no longer be able to bind to the “old” client or it might be able to track the new service as well now!
  • API vs. Impl. Vs. Consumer Versioning Syntactic vs. semantic incompatibilities (API tests as potential solution) Method/ property shadowing Dependency influence on versioning Wrong versioned artifacts Not linear version parsing/interpretation (always take the latest bugfix, but the minimal Minor/Major version possible)
  • How to create Manifest files and manage bundle creation
  • Most people didn’t like the default
  • Received a high vote in favor by the audience
  • The vote on the audience was more resistant, pro and cons equaled out and many didn’t vote at all.
  • How to create Manifest files and manage bundle creation
  • Signed bundles as a good way to identify the provider or assurance level on the quality. Revocation can be similarly implemented like with CRLs for browsers.
  • How to create Manifest files and manage bundle creation
  • Peter’s BND site: http://www.aqute.biz/Code/Bnd Apache’s BND site: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
  • < _plugin > aQute. lib .spring.SpringComponent </ _plugin > is interesting when you would like to analyse Spring DM configuration files as well.
  • Bundlor Website: http://www.springsource.org/bundlor Bundlor Introduction: http://blog.springsource.com/2009/03/20/getting-started-with-bundlor/ Bundlor in Eclipse: http://blog.springsource.com/2009/03/26/using-bundlor-in-eclipse/ Contributing to the SpringSource Enterprise Bundle Repository: http://www.springsource.org/repository/contribute OSGi Profiles: http://blog.springsource.com/2009/05/18/using-an-osgi-profile-with-bundlor/
  • Sample taken from: http://blog.springsource.com/2009/03/18/our-plans-for-building-osgi-applications/
  • Website: http://www.eclipse.org
  • PDE API Tools Homepage - http://www.eclipse.org/pde/pde-api-tools/ PDE User Guide - http://wiki.eclipse.org/PDE/API_Tools/User_Guide
  • PDE API Tools Homepage - http://www.eclipse.org/pde/pde-api-tools/ PDE User Guide - http://wiki.eclipse.org/PDE/API_Tools/User_Guide
  • Homepage: http://sourceforge.net/projects/javadiff/ Because of the lack of OSGi support, all classes within the bundle get analyzed, and too many results pop up. A limitation to the exported packages would be better (which is manually configurable, but a big cumbersome)
  • Remember!!! All presented here might sound like a lot of issues, but this is the price you pay when leading development. We reached with OSGi a level of componentization, no other technology has achieve yet, so it is obvious that we are facing new challenges. As they say, for one problem you solve, you’re most likely creating various new ones and that is exactly what we have right now.

Transcript

  • 1. Neil Bartlett Weigle Wilczek UK http://neilbartlett.name/blog Managing Change Mirko Jahn InterComponentWare AG, Germany http://osgi.mjahn.net
  • 2. Agenda
    • Where are we?
    • What we are working with
    • Versioning in practice
    • Tool support
    • Open challenges
  • 3. Heraclitus Ephesius (* 535 BC; † 475 BC ) “ Nothing endures but change.“
  • 4. Unknown Chinese Dude “ May you live in interesting times.”
  • 5. Dealing with Change
  • 6. How Microsoft does it
    • + Unique version numbers
      • + Fixed dependencies
      • + Assembly cache
      • Assembly qualified names
      • Versioning only on assemblies (not namespaces)
      • No flexible dependencies
      • No dynamism
  • 7. Doing it the Java way
    • Jars as unit of reuse (packaging)
    • Assumed always backwards compatible
    • No enforced dependency model
    • No built-in multi version support
    • No runtime (except for Applets and JEE)
    • No dynamism anticipated, but possible with limitations
  • 8. OSGi’s answer (in 2 slides)
    • Thin layer on top of (plain) Java
    • Enriched meta data to thoroughly describe the unit of reuse called bundle aka jar with:
      • Required dependencies
      • Exposed APIs
      • Runtime requirements
      • Strong version support
    • Sophisticated runtime to enforce modularity
  • 9. OSGi’s answer (in 2 slides)
    • In JVM services (Object references) to decouple API from implementation
    • Module dependencies designed on bundle and/ or package level
      • Import-Package vs. Require-Bundle header
      • Exposed API with Export-Package Header
    • Versioning theme: [[[[Major].Minor].Build].Revision] like: 1.3.2.iter1234
    • Ranges to flexibly define dependencies
  • 10. OSGi in Action a use case scenario
  • 11. Evolving APIs
    • Simple sample of a dictionary service
    • Taken from the Eclipse PDE sample
    • starting with 2 interfaces in package dictionary…
    • Implementation details:
      • Separation in two bundles (impl and api)
      • Dependencies on package level
      • User/ Client will be a simple command extension to proof the point
    V.1.0.0
  • 12. Evolving APIs
    • The implementation looks like this:
    dictionary.api 1.0.0 dictionary 1.0.0 dictionary.impl 1.0.0 [1.0.0,1.1.0) cl.client 1.0.0 [1.0.0,2.0.0) register s: dictionary.DictionaryService bind
  • 13. Evolving APIs
    • Small changes were introduced in the second version…
    V.1.1.0
  • 14. Evolving APIs dictionary.api 1.0.0 dictionary 1.0.0 dictionary.impl 1.0.0 [1.0.0,1.1.0) cl.client 1.0.0 [1.0.0,2.0.0) register bind dictionary.api 1.1.0 dictionary 1.1.0 dictionary.impl 1.1.0 [1.0.0,1.2.0) or register cl.client 1.1.0 [1.1.0,2.0.0) may bind [1.0.0,2.0.0) or or
  • 15. And in “real world”
    • Few people are using OSGi in such a highly dynamic fashion (yet)
    • Mostly the “is this bundle compatible with me” feature of versions is used and bundles get statically deployed as a product.
    • Getting versions right is tough!!! Currently we only version exports. Imports only if we really know what we are doing and require this feature
    • Typical problems you’re facing on a daily basis:
      • What dependency is it? API, Impl or Client?
      • Syntactic vs. Semantic incompatibilities
      • Method/ property shadowing in forward compatibility
      • Wrong/ incompatible versioned artifacts in official repositories
  • 16. OSGi Issues and Questions
  • 17. Gotcha Number 1
    • Any qualifier is “higher” than no qualifier.
    • Example: ROME (RSS/Atom library), an OSGi bundle developed by Sun Microsystems.
    • Release Candidate: Bundle-Version: 1.0.0.RC1
    • Release: Bundle-Version: 1.0.0
    • This default is surprising for new OSGi users.
    • Other systems (e.g. Maven, Jigsaw) use the opposite default.
  • 18. Related Gotcha: Remember your A,B,Cs
    • Release Candidate: Bundle-Version: 1.0.0.RC1
    • Release: Bundle-Version: 1.0.0.Final
    • Using “RC” doesn't leave enough space.
    • Recommendation: use Alpha, Beta, Candidate and Final.
    • May clash with existing corporate processes and policies for naming releases.
    • Or, just use a date/time stamp on each build. This is the Eclipse approach, but makes it hard to identify release versions.
  • 19. Gotcha Number 2
    • Beta 1: Bundle-Version: 1.0.0.Beta1
    • Beta 2: Bundle-Version: 1.0.0.Beta2
    • Beta 10: Bundle-Version 1.0.0.Beta10
    • Oops, 10 < 2!
    • Recommendation: zero-pad numbers in the qualifier, e.g. Beta01 .
    • Are 99 betas enough...?
    • .Net does not allow alphanumeric characters in versions at all.
  • 20. Gotcha Number 3
    • Import-Package: org.foo; version=”1.0.0”
    • Accepts 1.0.0 to Infinity!
    • Do we really want to accept ALL future versions of org.foo?
    • Is this an appropriate default?
  • 21. Choosing an Import Range (1)
    • Import-Package: org.apache.log4j;version=”[1.2,1.3)”
    • Informally 1.2.*. Will match all future versions up to but not including 1.3.
    • The most common choice. But this is a forward-looking statement .
    • But what if 1.2.32 (released in 2014 after the acquisition of Switzerland by OraGoogSunBay) breaks compatibility?
    • Cannot retrospectively change the released bundle. Must release a new version of our bundle with different import ranges.
  • 22. Choosing an Import Range (2)
    • Play it safe? Versions 1.2.13, 1.2.14 and 1.2.15 have been tested and are known to work, so:
    • Import-Package: org.apache.log4j;version=”[1.2.13,1.2.15]”
    • What if 1.2.16 is released tomorrow and is absolutely fine?
    • What if another bundle requires version 1.2.12?
    • Tight version ranges cause fragmentation.
  • 23. No Disjoint Ranges
    • Cannot say Import-Package: org.foo;version=”[1.0.0,2.0.0)” excluding 1.2 because it is buggy
    • Should we allow definition of disjoint ranges?
    • E.g. “[1.0,1.2) && [1.3,2.0)”
    • Makes a complex area even more complex.
    • Again cannot retrospectively add the exclusion.
  • 24. Lack of Semantics
    • The semantics of a version change are arbitrary.
    • Is version 1.3 of Log4J compatible with version 1.2?
    • There are suggested semantics but every library must be checked for compliance (and may stop complying at any time).
    • Only the authors of a library truly know whether 1.3 is backwards compatible.
  • 25. Idea: Reverse the Ranges?
    • Idea originally suggested by Peter Kriens to CPEG
    • Make exporters specify a range, not importers
    • E.g. Export-Package: “[1.0.0, 1.4.0]”
    • Meaning: “this is version 1.4 and it is compatible back to 1.0”.
    • Should importers still import a range, where any intersection in ranges will match?
  • 26. Non-Standard Semantics on Versions
    • Usually higher means better, but not always
    • E.g. Linux kernel, 1.1 and 1.3 are unstable, 1.0 and 1.2 are stable.
    • In production we should favour 1.2.18 over 1.3.1.
    • But in an lab/development environment we may favour 1.3.1
    • Do we need system policies defined by a deployer or administrator?
    • How on Earth could we manage such a policy if we have 1000s of packages?
    • A rule-based system may be necessary.
    • .Net allows limited overriding using a “publisher policy file”.
  • 27. Bundle Repositories
  • 28. Getting Bundles
    • Most 3 rd party libraries are STILL not OSGi bundles
    • Even if they are, they may have poor-quality metadata (e.g. ROME)
    • OSGifying libraries ourselves is a major drag
  • 29. Bundle Repositories
    • Some vendors have created bundle repositories with many open source libraries (e.g. SpringSource, Sonatype)
    • But how reliable are they?
    • If a bundle says Import-Package: org.foo;version=”[1.0,2.0)” , did the bundle creator really test every version in that range?
    • If not, where does this range come from? Did they just guess?
    • Who can I sue if it breaks??
  • 30. Verified Repositories
    • There is scope for a vendor to provide a truly verified repository backed by testing.
    • Probably needs to be a paid service – somebody who can be sued
    • What does it mean to test a library?
    • Need to support revocation when bundles are found to have problems
  • 31. Enhanced Querying
    • Existing repositories answer queries based on bundle name, package name, etc.
    • Can we partially offload resolving to the repository?
  • 32. Tooling support
  • 33. BND
    • Created by Peter Kriens, now under the Apache Felix umbrella (ASF 2.0 license)
    • Swiss Army Knife for bundle generation
    • Can be used as:
      • Command line tool
      • Eclipse plug-in
      • Ant task
      • Maven goal
    • Templating mechanism for version ranges
    • Source code analysis for imports
    • DS support
    • Macros
  • 34. BND
    • A sample configuration for the Maven plug-in (shortened):
    • ...
    • < plugin >
    • < groupId > org . apache . felix </ groupId >
    • < artifactId > maven -bundle- plugin </ artifactId >
    • < extensions > true </ extensions >
    • < configuration >
    • < manifestLocation > META-INF </ manifestLocation >
    • < instructions >
    • <!-- enable simple spring xml file analysis -->
    • < _plugin > aQute. lib .spring.SpringComponent </ _plugin >
    • < Export-Package > ${ osgi .export.package} </ Export-Package >
    • < Private-Package > ${ osgi .private.package} </ Private-Package >
    • </ instructions >
    • </ configuration >
    • </ plugin >
    • ...
  • 35. Bundlor
    • SpringSource’s tool to create Manifest files only
    • Mainly a template mechanism
    • The tool to use when contributing artifacts to their repo
    • Can be used as:
      • Command line tool
      • Eclipse plug-in
      • Ant task
      • Maven goal
    • Templating mechanism for version ranges
    • Source code analysis for imports
    • OSGi Profiles
  • 36. Bundlor
    • A sample configuration for the Maven plug-in (taken from SpringSource):
    • Manifest-Version: 1.0
    • Bundle-ManifestVersion: 2
    • Bundle-Name: GreenPages Service
    • Bundle-SymbolicName: greenpages
    • Bundle-Vendor: SpringSource Inc.
    • Bundle-Version: 1.0
    • Import-Template:org.springframework.*;version=&quot;[2.5.6.A,3.0)
    • Excluded-Exports: greenpages.internal
  • 37. Eclipse PDE
    • Manifest centric development of bundles
    • Many wizards and custom views to get you started
    • Live validation of your configuration based on the target platform definition
    • Integrated runtime to test you bundles without packaging them
    • Issues with fragments during development
    • Headless built possible
    • API tooling support…
  • 38. Eclipse PDE – API analysis support
    • Baseline centric API comparison mechanisms
    • Enriched with annotations
    • Eclipse and Ant support
    • Automated version increase according to the Eclipse versioning scheme possible
    • Identity leakage of non-API types into API
    • Many features are currently developed and will be included in Eclipse 3.5
    • Based on source code and generated meta data
    • OSGi aware
  • 39. Eclipse PDE – API analysis support
  • 40. jDiff
    • Source code based analysis
    • Can be used as Ant task, Maven goal or Command Line tool
    • Different types of reports like JavaDoc and XML
    • No OSGi awareness
  • 41. jDiff
  • 42. Remaining Questions
    • Versioning is not entirely explored
    • There is no suitable version scheme officially defined (no standard)
      • What is binary compatible
      • What is back-/ upwards compatible
      • In the context of OSGi how do dependency affect compatibility?
    • How to ensure the correctness of the applied versions?
    • Dynamic applications need new strategies for testing. How could one ensure the compatibility with the future versions and rule out incompatibilities for an almost infinite set of bundle combinations
    • How to ensure a bundle satisfies its version definition? (Certification?)
  • 43. State of the Art
    • NO existing tool can manage:
      • 1000s of packages
      • Multiple versions of each
      • Sensible import ranges
      • Different import range policies for different providers
  • 44. Conclusion
    • OSGi opens new opportunities, not imaginable before
    • Sophisticated versioning support available
    • A runtime that leverages using different versions, while guaranteeing compatibility as far as possible (if done right)
    • Still, the field is not entirely explored and needs further research
      • What implies a version is not satisfyingly defined
      • How to ensure software quality in a dynamic world
    • Tools are not there yet to remove the burden from the developer
  • 45. Questions & Answers Neil Bartlett Weigle Wilczek UK http://neilbartlett.name/blog Mirko Jahn InterComponentWare AG, Germany http://osgi.mjahn.net ?