Dynamic OSGi Applications (at WJAX 2008 and OOP 2009)

In the past years I have used OSGi mostly because of the modularity features. I loved to create small bundles with clear dependencies and visibilities between them - and I still do. I missed this kind of modularity in Java for so many years and I think that many teams still disregard this important modularity for their systems.

But I always knew that the module layer (the one I love so much) is only a small part of the OSGi world. The real coolness of OSGi comes with its dynamics. Using OSGi you can install, update and uninstall bundles at runtime without restarting the JVM. Wow! Doesn't this sound cool?

But wait. What the hack does OSGi do in those situations? If I start my applications, maybe thousands or millions of objects are created, relaxing in memory, referring to each other, talking to each other. Now this thing called OSGi updates a bundle at runtime. And my lovely objects? Are they updated magically under the hood and I don't need to take care of anything? Unfortunately (or I would say fortunately) not!!!

Nothing is done to my objects automatically. Instead I need to take care of those situations myself (which is good news in some way). I need to understand what it means having bundles that can come and go while my system is running (maybe under high traffic). And I need to carefully design my bundles to behave nicely within those situations.

Although its mentioned in every presentation on OSGi I assume that many people still don't know what this really means for building typical business applications. So many (and this includes myself) are used to build systems that are more or less a static set of deployed classes - once a release is deployed and used. Developers typically don't think about parts of the system being installed, updated or uninstalled at runtime without shutting down the application itself. And I think the structure of those systems reflects this. Even if the application is built out of a set of small bundles with clearly defined dependencies - in the end the transitive closure of the main application bundle contains everything. And the app assumes that once I have a reference to an object, this object will stay with me (and be fine) forever.

I observed this situation in some projects and it made me think about it from time to time. I talked to colleagues (namely Gerd Wütherich and Kai Tödter) about this and we discussed our experiences. The result is that we currently try to find some common best practices and patterns to write more dynamic systems than we did in the past for an upcoming talk at WJAX 2008 and OOP 2009.

I am pretty excited that there is so much more to learn how to build really dynamic systems with OSGi and I am sure that this will change the way I write and structure OSGi bundles in the future. Yours, too?

In the past years I have used OSGi mostly because of the modularity features. I loved to create small bundles with clear dependencies and visibilities between them - and I still do. I missed this kind of modularity in Java for so many years and I think that many teams still disregard this important modularity for their systems.

But I always knew that the module layer (the one I love so much) is only a small part of the OSGi world. The real coolness of OSGi comes with its dynamics. Using OSGi you can install, update and uninstall bundles at runtime without restarting the JVM. Wow! Doesn't this sound cool?

But wait. What the hack does OSGi do in those situations? If I start my applications, maybe thousands or millions of objects are created, relaxing in memory, referring to each other, talking to each other. Now this thing called OSGi updates a bundle at runtime. And my lovely objects? Are they updated magically under the hood and I don't need to take care of anything? Unfortunately (or I would say fortunately) not!!!

Nothing is done to my objects automatically. Instead I need to take care of those situations myself (which is good news in some way). I need to understand what it means having bundles that can come and go while my system is running (maybe under high traffic). And I need to carefully design my bundles to behave nicely within those situations.

Although its mentioned in every presentation on OSGi I assume that many people still don't know what this really means for building typical business applications. So many (and this includes myself) are used to build systems that are more or less a static set of deployed classes - once a release is deployed and used. Developers typically don't think about parts of the system being installed, updated or uninstalled at runtime without shutting down the application itself. And I think the structure of those systems reflects this. Even if the application is built out of a set of small bundles with clearly defined dependencies - in the end the transitive closure of the main application bundle contains everything. And the app assumes that once I have a reference to an object, this object will stay with me (and be fine) forever.

I observed this situation in some projects and it made me think about it from time to time. I talked to colleagues (namely Gerd Wütherich and Kai Tödter) about this and we discussed our experiences. The result is that we currently try to find some common best practices and patterns to write more dynamic systems than we did in the past for an upcoming talk at WJAX 2008 and OOP 2009.

I am pretty excited that there is so much more to learn how to build really dynamic systems with OSGi and I am sure that this will change the way I write and structure OSGi bundles in the future. Yours, too?

Dynamic OSGi Applications (at WJAX 2008 and OOP 2009)