Downloaded 26 times
A path to modularity with Eclipse Virgo
- 1. A path tomodularity with Eclipse Virgo Borislav Kapukaranov Katya Todorova March, 2012 Flickr: AbiKhairulAizad^^
- 2. In the idealworld... 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 thelong run Easy to maintain Loose coupling Clear contract Reuse © 2011 SAP AG. All rights reserved. 3
- 4. The path tomodularity is paved with... No product increment Backward compatibility issues Risk © 2011 SAP AG. All rights reserved. 4
- 5. Common pitfalls Versioning Semanticversions 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 jettyfor 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 themodularity 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 Manyexisting 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 6Web 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 builda 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 payoff © 2011 SAP AG. All rights reserved. 16
- 17. Juno Flickr: tecnico73 © 2011 SAP AG. All rights reserved. 17
- 18. Thank You! Contact information: BorislavKapukaranov borislav.kapukaranov@sap.com @bkapukaranov Katya Todorova katya.todorova@sap.com @katiatodorova
- 19. Startup size © 2011SAP AG. All rights reserved. 19
- 20. Footprint © 2011 SAPAG. All rights reserved. 20
Editor's Notes
- #6 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
- #16 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.
- #17 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.
- #18 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.