Why OSGi?... because software is long-distance, not a sprint-- by Graham Charters
Kathleenholm 2700009BHX Visits (5070)
Let's imagine you're starting a new development project. You're choosing what technologies you want to use. Java seems like a good start because your team has those skills and there are many existing projects and products you can draw upon. You've been given six months in which to deliver the project, so based on that you get your crack team together and start coding. Six months later you complete your last iteration, you've passed your quality criteria, the business is happy, job done. You've reached the finish line....or have you?
When making technology choices, what is often not considered is the full life-time of the application, or indeed the components that are created (or re-used) in that application. How many applications does the industry produce each year, and how many of those last for a single release and are never touched again? Very few, I would assert. The finish line for software is not when it's first delivered, it's when it reaches end-of-life. The business is likely to want enhancements and fixes for many years, so the right thing to do is factor this in to technology decisions. Most software projects are long-distance, not sprints.
So what's OSGi got to do with this? If base Java is Usain Bolt, then OSGi is Mo Farah (I'm a Brit, but feel free to pick your own favourite long-distance runner). Both are amazing athletes, but I wouldn't choose Usain to run the three miles to my nearest town to fetch me some milk. All too often we build software as if it's a sprint, and so it shouldn't come as a surprise that later in life it can't go the distance. Customers I speak to talk about "spaghetti code", "fear of making changes", "increased maintenance costs", and many more phrases that are all symptomatic of the same problem; as software projects evolve, the understanding of the architecture and design is lost - the understanding of the major components, their internals and their externals.
So how does OSGi help? OSGi lets you define modules (OSGi bundles) that have private implementation packages, hidden from accidental use, and public packages for use by other modules. They also describe the packages they require to be provided by other modules. Building software using OSGi does require an understanding of OSGi and effort to define the modules, so is likely to be slower initially (Mo would be slower than Usain over 100, 200, 400 meters), but where OSGi wins is in the fact that this information is captured in the software and enforced by the runtime. So as the software and team evolves the architecture is not lost, and can be consciously changed - the software lasts the distance.
It's no coincidence that most Enterprise Java Application Servers are built on OSGi. WebSphere Application Server was the first to move to OSGi in 2006 (v6.1), and since the release of the OSGi & JPA Feature Pack for v7, OSGi has been available to end customer applications (it's provided out of the box in v8 & v8.5). So, if you're a developer looking to start a new project, or have an existing project that's struggling to react to business requirements, you need OSGi to help you last the distance.
Want to find out more?
WebSphere Application Server V8.5 OSGi Applications on IBM Education Assistant:
Graham Charters is a Senior Technical Staff Member, WebSphere OSGi Applications Lead Architect and Master Inventor at IBM. He earned his PhD in Medical Biophysics at The University of Manchester.