OSGi Zone - Comments for "My thoughts about OSGi on JavaWorld"

One of the reasons why I've

sarbogast — Sun, 06 Apr 2008 05:17:00 -0400

One of the reasons why I've done this interview and why I try to write articles about OSGi is because I feel that the confusion I had made myself betwen OSGi and Eclipse is very frequent. So once again, OSGi and Eclipse (RCP) are two different beasts. In the context of Eclipse RCP development, the OSGi part is very vey small compared to JFace and SWT. So I would say that it is not really necessary for an Eclipse RCP developer to understand everything about OSGi. Event-handling, data-binding, the GUI framework are fare more important in this context.

On the other hand, OSGi knowledge is very useful when working with server-side technologies like Spring Dynamic-Modules.

That's right, I agree, this

dtobey — Fri, 04 Apr 2008 14:10:58 -0400

That's right, I agree, this kind of modularity would work equally well if not better with an open source application where the core code is open source. Any situation where you have numerous application developers working with the same base of code. I also agree with your point that this is why you do not see a lot of Java web applications where there are a lot of 3rd party add-ons. The war file is really limiting in that respect.

You mention the OS. I am a web developer and so I'm mainly interested in what this could mean for websites but the analogy is useful. In abstract terms there is a core set of functions any website needs: delivery of static content, session management, etc. At the same time the majority of websites need to draw from the same set of applications: CMS, a shopping cart, user forums, blog, chat, etc. Currently there is the Java portlet specification to help define how applications like this can work together in the same web space. I am not that familiar with the portlet specification, and I would be curious to know how OSGi and portlets are analogous. But could OSGi provide a more sophisticated solution? One could have a single OSGI application for the website, and these other applications could simply extend it, each providing extension points themselves for further customizations and improvements. In other words, OSGi could eventually provide a single, primary web application, sort of the RedHat of web applications, from which any other functionality is attached. I have not researched this idea enough to know if it is already something that has been developed or even makes much sense to anyone else. To me it seems to be the logical conclusion of OSGi on the server.

I totally agree with the

sarbogast — Fri, 04 Apr 2008 13:04:20 -0400

I totally agree with the advantages you mention. About the productization of OSGi bundles, I'm thinking about it too, but more with the Linux distribution model in mind. Imagine: you could have an Open Source application in the form of a distribution of free core bundles, and then you could develop custom modules on top of this free distribution and be paid to do so. Very similar to what RedHat does with Fedora.

... And basically when you

dtobey — Fri, 04 Apr 2008 12:15:01 -0400

... And basically when you have to change something in one of your modules, and your modules are just traditional JAR libraries, then you have to package the up again in a WAR or EAR, and deploy it again, so the application is restarted, and in some mission-critical applications, it can really be a problem. That’s really what makes Java not really modular, and I think the best demonstration for that is to see the number of platform-like applications in Java. You have plenty of CMS’s, project management systems and that kind of applications in PHP or other interpreted languages like Python and so on. But you have very few such systems in Java, and I think it’s more precisely because it’s more difficult to build an extensive, dynamic and modular application in Java.

Sebastian, this is a great explanation of what I find lacking too, in terms of Java web applications. I have been developing a shopping cart application in Java for several years now and this same architectural issue keeps coming up, which is why OSGi is very interesting to me as a way out of this. From my point of view the modularity of OSGi has these practical benefits, at least for me:

I would be able to write and deploy custom code on top of the core shopping cart, and undeploy it, without touching the core code. In situations where there are a lot of customizations that need to be done over the course of months and years, this would be a lifesaver because you could really separate core code from custom code and continue to install upgrades to the core code more easily.
A set of customizations, when wrapped up in and OSGi bundle, is extremely easy to reuse and share with other implementations. For me this has the practical benefit of being able to install a customization I do for one client on another client's implementation. Currently, I have to rifle through application configuration files, and concern myself a lot with integrating one set of customizations into another. Inevitably there is some manual merging involved.
The opportunity exists for OSGi bundles to be "productized". This is maybe more of a commercial, business advantage, but it can be a big one. It would apply to my shopping cart or really any other web application like the CMS's and project management systems you mention. A developer can write an extension or customization and share his bundle with anyone else, with low possibilities of it interfering with the functionality they have in place. This makes an after-market of application modules a much more realistic possibility for web apps, in much the way there is a healthy third-party market of Eclipse plugins.

dave