Be the first to like this
My keynote at Eclipsecon Europe 2013.
One of the attractive qualities of OSGi is its role in enabling technologies that adopt it to manage the cost of their own success. Anything that gains adoption - in technology or elsewhere - picks up baggage as a result and needs to figure out how to deal with current installations while expanding in new directions. The WebSphere platform has been around for almost as long as Java and knows a thing or two about baggage but still manages to travel to many places with just a carry-on allowance. We adopted OSGi internally 8 years ago and have gradually increased our exploitation with each passing release, most recently and deeply with the lightweight WAS Liberty Profile. It hasn't all been plain sailing and we learned from a number of mistakes made along the way. When WebSphere Application Server first adopted OSGi it had over 10 million lines of code in a modest number of huge JARs. The engineering effort to modularize that into a “sensible” number of OSGi bundles was fairly significant. We had a global development team spread across a dozen labs and nearly as many timezones, all learning OSGi principles at the same time. What could possibly go wrong? We did not, for example, initially adopt the services part of the OSGi architecture but it’s how we can now start/stop individual technologies of the Java EE Web Profile on the WAS Liberty profile, in a 50MB install with a 2-second startup, while still supporting a massive deploy base of applications on older levels of Java EE.
One of the challenges OSGi continues to face is over when to be “front of office” and when to be “back”. As the industry accelerates towards cloud, OSGi is an internal part of IBM’s strategy for high-density virtualized Platform-as-a-Service through WebSphere Liberty. Today’s cloud provisioning strategies, for example the buildpacks used by Heroku and CloudFoundry, are designed to be technology-agnostic. As a programming model for the cloud, OSGi is in a position of strength with its heavily service-oriented architecture. But in the spirit of agnosticism, one of the next steps OSGi needs to take is simply greater availability of the core OSGi framework in some of the more popular cloud platforms. Once there are more OSGi services running in those environments then the value and simplicity of autowiring OSGi services as cloud services becomes more apparent. Expectations and vision has to be managed up and down any organization that invests in OSGi - from the executive leadership team responsible for the business's bottom line, through the distributed architecture/development teams building tomorrow's technology on top of today’s, to the marketing and sales organization who need to sell the result to both IT and line of business. The value proposition has to be tailored to the audience.
This is the story of how WebSphere has had outstanding success with the former four-letter acronym that IBM Marketing still wants to expand.