OSGi DevCon 2012
Guidewire Software builds advanced applications for the insurance industry. With over a hundred customers in a dozen countries, including global giants like AXA, Geico, and Tokyo Marine, our applications handle tens of billions of dollars worth of business every year.
The Guidewire platform provides core services to its applications, and is oriented toward a high degree of customer extensibility. This talk is about the first phase of our project to migrate the Guidewire platform to OSGi. We describe our motivations for moving to OSGi, challenges we faced in "getting off the ground," and how we expect to take advantage of OSGi. Topics include:
Using bnd to build OSGi metadata
Using fragments to create an initial "mega bundle"
Embedding an OSGi container inside a J2EE app server
Bundling 3rd-party jars
Using Declarative Services as our component model
Integrating tools like bnd into a custom build and development environment
We also discuss how we plan to leverage OSGi, including:
Replacing a proprietary plugin architecture with OSGi services
Reducing the cognitive burden within development through truly separate components
Enabling testing in isolation, both at the class level and at the bundle level
28. Give Feedback on the Sessions
1
Sign In: www.eclipsecon.org
2
Select Session Evaluate
3
Vote
Notas do Editor
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…
Leads to frustration for new developers
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
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.
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
First step is get the platform and applications running in OSGi: replace the foundation
Just want to get the framework in place and prove that it can work.
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.
Last point is important in light of our goal: get platform running in OSGi framework without breaking existing code.
Learned about unresolved dependencies, duplicate packages/classes
