StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POCan OSGi help reduce complexity?
text
Body
copied!<p>I saw lots of presentations on <a href="http://www.osgi.org" rel="noreferrer">OSGi</a> and i think it sounds promising for enforcing better modularization. Apparently "hotdeployment" and "running different versions of x in parallel" are mayor selling points too.</p> <p>I wonder whether what OSGi promises to solve is even an issue...? It reminded me of the early days of OO when similar claims were maid: </p> <p><strong>When OO</strong> was new, the big argument was reusability. It was widely claimed that when using OO, one would only have to "write once" and could then "use everywhere". </p> <p>In practice I only saw this working for some pretty low level examples. I think the reason for this is that writing reusable code is hard. Not technically but from a interface design point of view. You have to anticipate how future clients will want to use your classes and take the right choices up front. This is difficult by definition and thus the potential reusability benefit often failed to deliver.</p> <p><strong>With OSGi</strong>, I have the suspicion that here again we could fall for promises, potential solutions for problems that we don't really have. Or if we have them, we don't have them in a big enough quantity and severity that would justify to buy into OSGi for help. "Hotdeployment" for example of a subset of modules is definitely a great idea, but how often does it <em>really</em> work? How often not because it turned out you got the modularization wrong for the particular issue? How about model entities that are shared between multiple modules? Do these modules all have to be changed at the same time? Or do you flatten your objects to primitives and use only those in inter-module communication, in order to be able to keep interface contracts?</p> <p><strong><em>The hardest problem</strong> when applying OSGi is, I would presume, <strong>to get the modularization "right"</em></strong>. Similar to getting the interfaces of your classes right in OO, with OSGi, the problem stays the same, on a bigger scale this time, the package or even service level. </p> <p>As you might have guessed, I'm currently trying to evaluate OSGi for use in a project. The major problem we have, is increasing complexity as the codebase grows and I would like to break the system up in smaller modules that have less and more defined interactions. </p> <ul> <li>Given no framework can ever help deciding <em>what</em> to modularize, has OSGi ever payed off for you? </li> <li>Has it made your life easier when working in teams?</li> <li>Has it helped to reduce bug count?</li> <li>Do you ever successfully "hotdeploy" major components?</li> <li>Does OSGi help to reduce complexity over time?</li> <li>Did OSGi keep its promises? </li> <li>Did it fulfill your expectations?</li> </ul> <p>Thanks!</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload