0. Moving the Guidewire platform to OSGi
A case study
Paul D’Albora
Guidewire Software
March 2012

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

2. 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

3. 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 …

4. We’re all probably familiar with this metaphor
We’re all probably familiar with this metaphor. It’s a natural consequence of code evolution without proper boundaries. Tug on one strand and you affect something on the other side of the “plate.” And we all know where this leads…

5. Leads to frustration for new developers

6. Goals Test components in isolation Reduce learning curve
Contain maintenance costs
Release components independently
Understanding the pressures we face on the platform team, and that those are only likely to increase, we defined some goals we’d like to have in order to survive.
Testing in isolation: we invest a lot in automated testing. Over time, more and more of our tests have had to be written as integration / end-to-end tests. We attempted to use mocks for more “unit” style testing, but our components are not de-coupled enough for that to work.
New developers face a daunting challenge. No clear APIs, sub-systems tightly coupled
Fixing bugs often requires knowledge over a broad area of the platform
Platform must be delivered as a monolith

7. OSGi Module system Versioning Manageability
Mature, well-defined specifications
Robust community
Services!
We decided to go with OSGi
Module system provides a way to define boundaries and enforce them
Has momentum
Manageability is a big advantage – modular architecture allows for wide array of introspection tools
Service layer is a simple but extremely powerful way of de-coupling code. Combined with Declarative Services, it is the most exciting aspect for us.

8. 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
How are we going to get there? Here’s what we’ve got to work with.
Customers familiar with and have expertise with managing their own JEE application servers. From their point-of-view, it’s still just a WAR.
PL, apps depend on PL
For development, no access to PDE
Custom, script-based build system

9. Step 1
First step is get the platform and applications running in OSGi: replace the foundation

10. 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
Just want to get the framework in place and prove that it can work.

11. Roadblocks

12. 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
Renaming packages is not an option at this point. Neither is co-locating the packages. This is not unusual when the package doesn’t mean much.

13. 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
Last point is important in light of our goal: get platform running in OSGi framework without breaking existing code.

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

15. Solution: Varied Public OSGi bundle repositories BND
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
Learned about unresolved dependencies, duplicate packages/classes

16. 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>)
Entry points to the applications

17. 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 to HttpService

18. 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

19. 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
Not yet released to customers

20. 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

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

22. Static Service Registry – Code Sample 1

23. Static Service Registry – Code Sample 2

24. Static Service Registry – Code Sample 3

25. Static Service Registry – Replacement

26. Questions?
Feedback welcome.

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