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
“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,”
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.