Recommandé
Contenu connexe
En vedette
En vedette (7)
Similaire à A path to modularity with Eclipse Virgo
Similaire à A path to modularity with Eclipse Virgo (20)
Dernier
Dernier (20)
A path to modularity with Eclipse Virgo
- 1. A path to modularity with Eclipse Virgo Borislav Kapukaranov Katya Todorova March, 2012 Flickr: AbiKhairulAizad^^
- 2. In the ideal world... A collection of modules complement each other; their sum is greater than each part. No waste, nothing to spare. Flickr: alicejack2002 © 2011 SAP AG. All rights reserved. 2
- 3. Benefits on the long run Easy to maintain Loose coupling Clear contract Reuse © 2011 SAP AG. All rights reserved. 3
- 4. The path to modularity is paved with... No product increment Backward compatibility issues Risk © 2011 SAP AG. All rights reserved. 4
- 5. Common pitfalls Versioning Semantic versions vs reproducible build Uses clauses Import-package vs Require-Bundle Optional packages Start levels How do we model core functionality? © 2011 SAP AG. All rights reserved. 5
- 6. “Google chose jetty for App engine” Jetty is designed to be at Jetty pluggable and fe atures th extensible, so Google The key osen for were was ch ility.” have been able to size and flexib customize it to a high degree. http://www.infoq.com/news/2009/08/google-chose-jetty
- 7. Virgo in the modularity world Standard OSGi Bundles All the Way Down Diagnostics ++ deadlock detection unsatisfied DS notifications extensible and independent web console extensible dump generation mechanism enhanced OSGi utilities sophisticated event logging and tracing Virgo White Paper © 2011 SAP AG. All rights reserved. 7
- 8. DEMO Unsatisfied DS notifications © 2011 SAP AG. All rights reserved. 8
- 9. Virgo Features Nano OSGi, Diagnostics ++, DS, p2 Kernel Being good citizens in both EE and OSGi world support (Subsystems coming) side-state resolution Virgo repositories Blueprint in the user region Load-time weaving Tomcat Server / Jetty Server Web container © 2011 SAP AG. All rights reserved. 9
- 10. Virgo supported artifacts Nano jar (WAB); WAR Kernel jar; PAR; Plan, property files Tomcat Server / Jetty Server jar (WAB), PAR; Plan; WAR, property files © 2011 SAP AG. All rights reserved. 10
- 11. Virgo use cases Nano Nano Base –Equinox + Diagnostics –Embedded –Good base for OSGi apps of any kind Nano Full –Nano Base + Web layer (+ p2) –Lightweight app server –Cloud environment © 2011 SAP AG. All rights reserved. 11
- 12. Virgo use cases Kernel Multi-region environment Many deployment options Clustering via Cloning Isolated and more stable core Tomcat Server / Jetty Server Web App Servers Enterprise apps (Spring, Hibernate) Standard web apps run in OSGi © 2011 SAP AG. All rights reserved. 12
- 13. Let me choose Many existing apps are not OSGi aware Often migration is not an option Being good citizens in both EE and OSGi world is worth the effort © 2011 SAP AG. All rights reserved. 13
- 14. Java EE 6 Web Profile Servlet/jsp EJB 3.1 Lite Persistence 2.0 Transactions 1.1 CDI 1.0 © 2011 SAP AG. All rights reserved. 14
- 15. How to build a Web server from scratch? How do we know we’ve done it right? Does following the modularity path pays off? © 2011 SAP AG. All rights reserved. 15
- 16. It did pay off © 2011 SAP AG. All rights reserved. 16
- 17. Juno Flickr: tecnico73 © 2011 SAP AG. All rights reserved. 17
- 18. Thank You! Contact information: Borislav Kapukaranov borislav.kapukaranov@sap.com @bkapukaranov Katya Todorova katya.todorova@sap.com @katiatodorova
- 19. Startup size © 2011 SAP AG. All rights reserved. 19
- 20. Footprint © 2011 SAP AG. All rights reserved. 20
Notes de l'éditeur
- When best practices in different domains clash there’s no an easy solution: Build systems usually recommend a concrete version for the dependencies rather than range. JEE heavily use META-INF/services concepts which implies that this package is accessible. Optional packages are often declared as optional but no extra care is taken in the source to handle the case when the package is not available Split packages across third party jars are common case and usually refactoring is not an option so sometimes require-bundle is preferable. Guarantee start sequence without services could be tricky and start levels could help as workaround. Drawbacks of that approach (mostly on system update) could be found in every article on OSGi best practices. No silver bullet (yet) just list of open questions which to be considered from multiple perspectives
- A modularized JavaEE stack exists. Clears the way for owners of standard monolithic JavaEE apps to start modularizing bit by bit. Experience and Virgo users tell us that once you modularize your app you don’t want to go back to a monolithic approach.
- Because everything is so modular and the components we used are relatively loosely coupled we were able to assemble a minimal set of components that satisfy our goal of EE support.
- Our goal is to have the Virgo Nano-EE distribution part of the Eclipse Juno release train. It is scheduled for release on June 27th.