Managing Change
•Transferir como PPT, PDF•
3 gostaram•1,006 visualizações
Presentation at the OSGi DevCon 2009 in Zurich. Presenters: Neil Bartlett Mirko Jahn
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Managing Change
Semelhante a Managing Change (20)
Último
Último (20)
Managing Change
- 1. Neil Bartlett Weigle Wilczek UK http://neilbartlett.name/blog Managing Change Mirko Jahn InterComponentWare AG, Germany http://osgi.mjahn.net
- 3. Heraclitus Ephesius (* 535 BC; † 475 BC ) “ Nothing endures but change.“
- 4. Unknown Chinese Dude “ May you live in interesting times.”
- 10. OSGi in Action a use case scenario
- 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
- 16. OSGi Issues and Questions
- 32. Tooling support
- 39. Eclipse PDE – API analysis support
- 41. jDiff
- 45. Questions & Answers Neil Bartlett Weigle Wilczek UK http://neilbartlett.name/blog Mirko Jahn InterComponentWare AG, Germany http://osgi.mjahn.net ?
Notas do Editor
- 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.