Mule Drop OSGi For Being Too Complex
Ross Mason’s blog describing why OSGi isn’t for Mule, marks a return to ‘is OSGi too complex?’ debate.
Ross Mason has blogged about why OSGi just isn’t for Mule. The sticking point for him and the Mule team, was their inability to hide the complexities of OSGi from their end users, to a degree they found satisfactory. Their attempt to implement OSGi, has led Mule to conclude that OSGi is a great specification for middleware vendors, but not so good for the end users. Ross Masson views OSGi as a specification originating from set-top boxes that required software updates being deployed remotely without user intervention, and therefore it has not developed along lines well-suited for application developer consumption.
“Middleware vendors have jumped on OSGi because, frankly its right up our street. 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,” he writes.
Once again, we’re back to the argument of OSGi being too complex. Ross Mason views the complexity and technicality of developer-focused OSGi blogs, as proof that OSGi simply isn’t ready for the developer yet. He believes OSGi should be “completely invisible to a developer” and, currently, it clearly isn’t. He does have a few kind words to say about OSGi though: its fundamental principles are sound. We do need modularisation on the JVM, and if the next revision of the specification focused on making it less painful to work with OSGi bundles, then the Mule team would be happy to re-evaluate their ‘no OSGi’ stance. “I think OSGi has potential but the user interaction part of it needs to be re-thought now that OSGi is being targeted at regular application development,” is his conclusion.
Dmitry Sklyut has posted a reply, arguing that OSGi is a Dynamic Module System for Java, and it is not OSGi that is difficult, but modularity: “properly drawing boundaries between components is hard. Getting communication protocols and APIs right is hard. Unlearning habits of the past is hard.” Furthermore, as a dynamic solution, OSGi is again going to be tricky, as “dynamic is not something that a regular developer ever learned to deal with properly.” He asks OSGi naysayers to take a look at the history of enterprise Java and its ecosystem of tools, and all the effort that has gone into making writing Java apps ‘easy’ for developers – maybe the community is just at the start of their OSGi journey. Currently, there isn’t enough documentation and people who are using OSGi are not always easy to come by – therefore, if you hit an OSGi-related problem you might have to work through it by yourself. This idea has already been discussed in the community, with Kirk Knoerschild stating “there is a stark difference between complexity brought on by lack of tooling and platform support versus complexity associated with an ill-conceived idea.” Ian Skerrett has also acknowledged that a lack of supporting documentation, creates a steep learning curve for OSGi newbies. This is an issue that can only be resolved over time and, with containers like Apache Karaf and Eclipse Virgo, and OSGi books such as OSGi in Action and Spring DM in Action, he believes we are already on the right track.
So, if OSGi is gradually building up the ecosystem of tooling, documentation and user experience necessary to support developers, then what does Dmitry Sklyut see as the problem with OSGi? Put simply, it’s fear of the unknown. OSGi is simply a different programming mode. Ultimately, it is up to the individual developer to decide whether learning OSGi and overcoming the learning curve, is worth the benefit of modularity.