1 / 28

Moving the Guidewire platform to OSGi

Moving the Guidewire platform to OSGi. A case study. Paul D’Albora Guidewire Software pdalbora@guidewire.com March 2012. Agenda. Introduction to the Guidewire platform Motivation for moving to OSGi Challenges Where we are and where we’re going Q & (hopefully) A.

rkrause
Download Presentation

Moving the Guidewire platform to OSGi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Moving the Guidewire platform to OSGi A case study Paul D’Albora Guidewire Software pdalbora@guidewire.com March 2012

  2. Agenda • Introduction to the Guidewire platform • Motivation for moving to OSGi • Challenges • Where we are and where we’re going • Q & (hopefully) A

  3. The Guidewire Platform – Basics • Supports core system software for the global property/casualty insurance industry • Core services: ORM layer, web UI framework, business rules, workflow, automated upgrade, I18N, customer plugins, messaging and web services integration • High degree of configurability • Supports multiple JEE containers

  4. The Guidewire Platform – Pressures • Constantly adding and improving features for applications • Must not break existing customers • Large code base developed over ten years • Large and growing development team • All of which can lead to …

  5. Goals • Test components in isolation • Reduce learning curve • Contain maintenance costs • Release components independently

  6. OSGi • Module system • Versioning • Manageability • Mature, well-defined specifications • Robust community • Services!

  7. Givens • Application must be delivered as a JEE application (EAR/WAR) • Code divided into coarse-grained “modules” forming a DAG of compile-time dependencies • Non-Eclipse IDE (no PDE) • Custom build system

  8. Step 1

  9. Plan • Run Equinox embedded in JEE container using servlet bridge • Define a bundle for each existing code “module” • Replace/Convert 3rd-party jars with OSGi equivalents • Get automated tests running in framework • DON’T try to modularize yet

  10. Roadblocks

  11. Problem: Split Packages • Same package exists in multiple modules • Framework binds to one of them, causing the other “parts” of the package to effectively disappear • Typical for platform and one or more applications to define classes in the same package • This is pervasive in our code

  12. Solution: Fragments • Define an empty “root” bundle • Every bundle is a fragment of root • Fragment-Host: com.guidewire.root • Simulates one bundle • More closely represents original, non-modular, global classpath environment

  13. Problem: 3rd-party libraries • Lots of them (~102) • Signed jars • Classpath assumptions

  14. Solution: Varied • Public OSGi bundle repositories • Eclipse Orbit • SpringSource • BND • For signed jars, embed jar within jar and use Bundle-ClassPath • Can combine related jars to deal with split packages • TCCL to work around classpath assumptions • Newer jars being packaged as OSGi bundles

  15. Problem: Servlets • No longer registered in web.xml (just the servlet bridge) • How to register platform and application servlets with HttpService • Ordering requirements (<load-on-startup>)

  16. Solution: Components • Felix Http Whiteboard • Declarative Services with Bnd • @Component(provide=Servlet.class, properties="alias=/path") • For ordering-dependent servlets, register in order with HttpService • Component with @Reference to HttpService

  17. Practical Tips • Learn and use BND • Learn the classloading flow chart (R4.2 Spec, Fig 3.19) • Turn off osgi.compatibility.bootdelegation, osgi.context.bootdelegation in Equinox • No Require-Bundle • Lean on automated tests • Use the framework itself

  18. Current Status • Applications and integration tests running successfully in development • Initial performance testing reveals no significant difference in response times or memory usage • Rolled out to application teams with minimal disruption

  19. Next Steps • Define candidate areas for modularization • Use services to de-couple components • Use services to replace ad hoc registries • Educate developers about service-oriented programming

  20. Example: Static Service Registry • Map of interface Class to implementation instance • Initialized by bootstrap class • Accessed via static methods

  21. Static Service Registry – Code Sample 1

  22. Static Service Registry – Code Sample 2

  23. Static Service Registry – Code Sample 3

  24. Static Service Registry – Replacement

  25. Questions? Feedback welcome.

  26. Give Feedback on the Sessions 1 Sign In: www.eclipsecon.org 2 Select Session Evaluate 3 Vote

More Related