I've been travelling a lot recently and this week I'll be
speaking at EclipseCon Europe, in Ludwigsburg Germany, on.....
Travelling Light for the Long Haul. I quite like using long-distance travel, with all its potential discomforts, as an analogy for long-lived software projects. The more you do the travel, the more you plan ahead with strategies for making it smoother and more comfortable for yourself. Today, for example, I'm travelling economy (as always...) but writing this from a business lounge.
I'll be giving a keynote on the OSGi track and I'll start off by looking at how OSGi has enabled one of IBM's most successful software products to survive and thrive in a challenging market.
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? I’ll spend a little time reviewing the consequences of our bundles-first-services-later approach but our success was initially limited to having the equivalent of a well-organized and large container ship which could travel at speed but needed a pretty wide berth. Our initial investment in OSGi delivered on most of the internal benefits we wanted but failed on some of the external ones that matter to our customers.
Application Servers are used in different ways by Developers and IT Operations. Ops teams care about the overall cost, including performance and availability, of the platform and the applications it supports; Dev teams care about how quickly and easily they can create and deliver their applications and treat the server as a tool. Only some of them know or care about OSGi; multi-channel enablement and cloud deployment are the current pressures they are under. Today, WebSphere is a consumer of OSGi in two distinct fashions. Internally we learned from our earlier experiences and embraced an OSGi services model to enable us to run the same runtime just as fast but in a far more dynamic fashion: it’s how we can start/stop individual technologies of the Java EE Web Profile independently on the WAS Liberty profile, in a 50MB install with a 2-second startup while still support all our customers’ existing deployments. Externally we support both Enterprise OSGi and traditional Java EE as application programming models, on the same runtime and using the same Eclipse-based tools. Our customers who understand and care about OSGi can develop and deploy web application bundles and multi-bundle enterprise applications. Those who don’t care about OSGi benefit from it indirectly through the OSGi subsystem features that provide the server capabilities their applications use.
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.
We’ve taken some steps in this direction already with a WebSphere Liberty buildpack for the Cloud Foundry PaaS
which provides an OSGi container (using WebSphere and Eclipse Equinox) for enterprise OSGi applications – you just bring your bundles and push them to the cloud.
Come and hear more at EclipseCon. I’ll be speaking on Hallowe’en…
Ludwigsburgers (if thats a reasonable way to describe the people of
Ludwigsburg) know how to celebrate Hallowe'en. They have the most
brilliantly mad display of pumpkin sculpture I've ever seen. I don't know how this exhibition ever got the green light, but I'm glad it did. "I know,
lets model all the events of the Olympic games as pumpkin sculptures!".
And why not? Swimming, ski-jumping, discus, bob-sleigh,
weight-lifting...its all there in the beautiful baroque gardens of
Ludwigsgburg palace.
