Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Is OSGi the Right Foundation for Java Middleware?

Is OSGi the Right Foundation for Java Middleware?

This item in japanese

The OSGi working group started in 1997 as the JSR 8, mostly focusing on embedded Java with the goal of supporting modular updates to embedded software. OSGi became mainstream after solving the inextricable dependencies of Eclipse plugins.  Right about 2005, several approaches converged towards bringing more modularity to Enterprise Java by leveraging assembly mechanisms and well defined dependencies, including Spring and Service Component Architecture while EJBs, slowly faded away. Today most Enterprise Java vendors have rewritten their middleware on an OSGi foundation.

Yet, there has been lots of frustration with the technology and Ross Mason, founder of MuleSource, let it all out on his blog a couple of days ago. 

OSGi was going to change everything, dependencies would be completely isolated (no more tripping over conflicting dependency versions), visibility and would be strictly enforced between each ‘bundle’. I was so bought into the promise of OSGi, like many others, I focused our engineering team on making Mule OSGi-enabled.
After months of our team wrangling with manifests, packaging our own bundles and endless fiddling with our build, the benefits of OSGi started to dwindle. ‘No pain no gain’ we thought, but then we hit our roadblock. 

His engineering team could not see how to hide the complexity of OSGi to middleware developers. He sees the problem stemming from the embedded roots of OSGi

OSGi is a great specification for middleware vendors, ...[but] OSGi was never build for application developer consumption. Its roots lie in set-top boxes that needed to have software updates deployed to them remotely without any user intervention. It is a great specification for this type of software deployment since only the vendors needed to deal with deploying bundles.

Modularization and versioning are two core problems in middleware projects. Service implementations change often (sometimes on a quarterly basis) and in the past large organizations often deployed all their services in a single ear file, every three month, creating major synchronization issues between consumers and service providers, not to mention testing all the services all the time, even though many in the ear might have never changed nor relied on the new or updated services. One could argue that poor modularization and lack of versioning alone are responsible for most of the claims that SOA is a failure. Ross adds:  

[OSGi] It promises to modularize software stacks and enable plug n’ play of your middleware infrastructure. Unfortunately, not even these promises are easily delivered with some bundles not working the same way across different containers.

Ross sees the principles behind OSGi as being the right ones for an evermore heterogenous stack. But for him:

the user interaction part of it needs to be re-thought now that OSGi is being targeted at regular application development. As it stands modularization and hot deployment is very possible on the JVM without OSGi and the pain of day-to-day development with OSGi out-weighs its benefits.

Neil Bartlett responded to Ross:

tools like bnd do already make OSGi nearly invisible to the developer. The problem right now, I believe, is that the choice of alternative approaches and tools for developing on OSGi is overwhelming. I remain convinced that the pain of day-to-day JVM development *without* OSGi out-weighs any of the short-term benefits....When’s the last time you wrote a .class file by hand? Probably never, you compile it from Java source. The OSGi manifest is the same kind of thing, it should be the output of a compiler-like tool. 

Joe sampson shared his experience with OSGi which he found hard to use from a testing and build perspective. Hani Suleiman noted

OSGi is a good model on a conceptual level, it’d just too hampered by the language not natively supporting it. The reluctance to start over with all that we’ve learned has meant that it’ll always remain an obnoxious unwieldy framework that nobody (that I know of, obviously if all you hang out is OSGi fruits then your experience will differ) honestly enjoys using.

Richard S. Hall added a word of caution:

If you come to OSGi and expect all legacy JARs to work perfectly and still reap all of the benefits of modularity, then you might as well not even try. That’s sort of like switching from C to C++ back in the 1980s and just hoping that everything automatically becomes object oriented.

Paul Fremantle, CTO of WSO2, responded to Ross, explaining that WSO2 Carbon is not only built on OSGi but completely hides OSGi from the developer. He acknowledge that it was not easy, but it was easier than building their own approach to modularization, versioning and provisioning.

What is your take on OSGi? Did you struggle ? Is it transparent to you? Is your middleware modular enough and support a world class versioning strategy? Could it be that we will always be bound to hit an architectural dead end as the core problem of modern architectures will always be the lack and mismatch of semantics with the ones of the underlying programming language, as Hani pointed out?

Rate this Article