1. OSGi at a Large-Scale Enterprise Lessons from eBay Justin Early, Sangjin Lee, & DebashisSaha eBay Inc.
2. Agenda Case for enterprise OSGi Speaking of scale... Migration challenges & observations IDE & build Tooling benefits Closing 2
3. Case for enterprise OSGi For all its virtues, OSGi is still a hard sell in (large scale) enterprises Why? 3
4. Case for enterprise OSGi Modularity: warm Runtime dynamism: not so much Operations needs predictability JavaEE containers are becoming OSGi ready: warm 4
5. Modularity Modularity is perhaps the best driver for OSGi in the enterprise Reduce surface areas Reduce coupling and increase cohesion However, modularity benefits are hard to quantify What is a PRACTICAL metric that demonstrates the compelling value of a modular architecture? Reduced coupling? Reduced build time? 5
6. Cost-benefit analysis Modularity benefits are long term, but the migration pain is immediate The very SCALE which necessitates the modularity discussion also makes migration very expensive 6
8. Speaking of scale... eBay’s code base has Thousands of jars Tens of thousands of packages Hundreds of thousands of classes Tens of millions of lines of code Even the simplest refactoring can become very expensive 8
9. Migration observations Everything needs to be in a bundle We’re finding a lot of existing problems to clean up Starting from a “super” bundle 9
10. Migration challenges What should be my module granularity? Package control policy Import-Package v. Require-Bundle (ala split packages) Dynamic classloading and resource loading 10
Do we need to adopt Plugin Development Environment (PDE) or Java Development Envrionment? Do we change how we develop or can we just use POJO projects?We find that PDE in eclipse can build plugins if we handcraft manifest.mf and use the manifest editorWe have used BND to generate manifest.mf and export bundles from our existing POJO build processWhat (headless) build framework will scale?Module-aware builds – like the idea of javac wrapper to compile from a list of modules
Can OSGi help with managing a Java API other than basic Java access?Developer classpath construction is minimized: this is important with a very large number of librariesTools to help exploring the modulesPromising Workspace materialization leveraging OSGi metadataControl packages that are exportedControl packages that are shared between modules (friend)Control packages that are internal.API baseline management and tooling is being added to PDE tooling in EclipseCompiler will highlight packages that are discouraged from usage and not available for usage.Number of dependencies have increased the size of the classpath causing order issues and issues with cross packages which could be caught with a module system.Visual tools for seeing dependencies no development cost these tools use OSGI manifest data to create tree.Tools to author manifest files already available in EclipseClass path container simplifies view in Eclipse no more filtering out libraries from External.Find bundle / jar compile time dependencies that are unused is a tool within Eclipse.Find all classes used from this bundle is now possible.