To OSGi or not to OSGi?
I had a long discussion with Peter Kriens of the OSGi alliance after his JavaOne 2011 presentation “Why OSGi?’. In that talk he made a pretty compelling case that we are in the midst of a progression of visibility control that has been introduced first by subroutines and functions, then objects with the advent of SmallTalk, then packages, and now modules/bundles, (And next, perhaps something around WebServices?) that has been evolving in a world of growing and more complex code bases.
I expressed to him my main concern about moving to OSGi as a firm standard - the cost of financing the learning curve. Peter’s suggestion was to have a little tooling and a small trained OSGi staff that can set up the skeleton of each project and hand that off to the development teams, who can then remain blissfully ignorant of OSGi.
The reward – more maintainable code in a milieu where the amount of software written will double in the next 6 years.
I asked him about project Jigsaw and his feeling was that it is missing the boat – only scoring a 2 or 3 out of 5 on his Modularity Maturity Model. He also said Mark Reinhold and team have a lot of learning curve ahead of them and his opinion was they will never catch up with OSGi!
Ok, I would expect him to say that, but I am inclined to believe it, especially over the next 3 or 4 years before Jigsaw enters the scene.
My big question is – are firms ready to stand behind OSGi as a basis of a platform?
My feeling is that something like Paremus has a light footprint, fast startup, auto scaling, multi-tenancy, and provides standard SE functionality plus basic JEE functionality (courtesy of CXF and open EJB) all without an app server. If not Paremus, there will probably be entries by larger companies coming, perhaps GlassFish is already that, but I prefer Paremus because it accommodates non-OSGi code side by side, providing for an evolutionary migration strategy.
But will CIO's agree with that argument (which is largely based on the nebulous benefits of modularity) or will it all come down in the end to the basics – what is the cost saving, enterprise apps require Java Enterprise Edition, why support multiple containers, etc. etc. Egad! If we made those arguments in the 80’s we would still be programming in PL/1!
Can we make a business case for JAP SE that is largely dependent on OSGi?
I am anxious to hear your opinion.
I expressed to him my main concern about moving to OSGi as a firm standard - the cost of financing the learning curve. Peter’s suggestion was to have a little tooling and a small trained OSGi staff that can set up the skeleton of each project and hand that off to the development teams, who can then remain blissfully ignorant of OSGi.
The reward – more maintainable code in a milieu where the amount of software written will double in the next 6 years.
I asked him about project Jigsaw and his feeling was that it is missing the boat – only scoring a 2 or 3 out of 5 on his Modularity Maturity Model. He also said Mark Reinhold and team have a lot of learning curve ahead of them and his opinion was they will never catch up with OSGi!
Ok, I would expect him to say that, but I am inclined to believe it, especially over the next 3 or 4 years before Jigsaw enters the scene.
My big question is – are firms ready to stand behind OSGi as a basis of a platform?
My feeling is that something like Paremus has a light footprint, fast startup, auto scaling, multi-tenancy, and provides standard SE functionality plus basic JEE functionality (courtesy of CXF and open EJB) all without an app server. If not Paremus, there will probably be entries by larger companies coming, perhaps GlassFish is already that, but I prefer Paremus because it accommodates non-OSGi code side by side, providing for an evolutionary migration strategy.
But will CIO's agree with that argument (which is largely based on the nebulous benefits of modularity) or will it all come down in the end to the basics – what is the cost saving, enterprise apps require Java Enterprise Edition, why support multiple containers, etc. etc. Egad! If we made those arguments in the 80’s we would still be programming in PL/1!
Can we make a business case for JAP SE that is largely dependent on OSGi?
I am anxious to hear your opinion.
Labels: Osgi Java
posted by Victor Grazi at 12:16 PM
0 Comments:
Post a Comment
<< Home