As I've been pondering ways to improve the configurability of my work project across multiple deployments, OSGi has suggested itself as a potential solution. Primarily, I would like to allow other deployments to select the set of modules, and the implementations of these modules, that are placed into use in various production environments. Though I soon realized that our current Spring-based configuration mechanism is probably sufficient for managing this level of configurability; one merely needs to change the implementation classes that are defined in a XML file. And so OSGi might be too heavy weight of a solution. The main benefit of an OSGi solution, as I see it, is the ability to dynamically swap in and out these subsystems. But this dynamicism is not really necessary for my project, since deployments are fairly static once configured.
But then I thought to myself, how nice would it be to be able to replace modules during development without having to restart the application server? This is one of the larger time sinks developers face while developing web apps. In fact, it's enough of a problem that it spawned a commercial solution, JRebel (why I haven't tried this out already, is beyond me!). Shouldn't an OSGI app, if designed properly, be able to address this problem as well? If only a minimal skeleton of code is needed to bootstrap the app, and the majority of the code is comprised of OSGi bundles, then shouldn't we be able to dynamically update pieces of our running web app? I need to look into this further.
One other benefit of OSGi is the "runtime enforcement of module boundaries" [ref]. That's a very appealing feature, as well.
Since the Spring application framework now has OSGi support, it may not take too much to move to an OSGi-based design.
Tuesday, February 9, 2010
Subscribe to:
Posts (Atom)