Java Champion / JavaOne Rockstar Adam Bien ( is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

How To Kill An OSGi Project - With 10 Questions

  • submit to reddit

OSGi focusses on modularity and it is right now (future may change it) the only viable way to split your application into modules with well-defined dependencies. It solves, however, "only" the technical problem - which is actually relatively easy. Before you going to introduce OSGi into your project, answer the following questions:

  1. What is your versioning scheme for modules(bundles)? Do you care about minor versions, major versions etc?
  2. Whats your scm strategy - do you plan to open and maintain a branch for every version of a module? How many branches do you plan to maintain? (with svn? :-))
  3. How many versioned modules will be active at the same time in production?
  4. How the system is going to be tested? Each module and all the combination of modules. Every version will increase the complexity significantly.
  5. What is your release-management strategy? Do you really plan to provide customer-specific module combinations? What is your bug-fixing / patch strategy (trunk, branch)?
  6. Do you really want to replace modules in running system? If it is a serverside system - what happens with in-flight transactions?
  7. If it is an Eclipse-RCP application - are you even allowed to expose the plugins to the end-user? (in the majority of my projects, we had to disable the update manager in production :-))
  8. What is your software distribution system - many companies have already a software-distribution system in place. Often not only the application, but also the JVM are packaged into one binary file and entirely installed. Incremental updates are often impossible.
  9. What is exactly the contract between the modules? Only a Java-Interface? If so - what to do with direct relations between JPA-entities. If you disallow direct JPA-relations - you will probably see a huge "domain" package with all domain objects inside it. You will need to provide "friend" relations between modules as well.
  10. Is maven the canonical representation of modules, OSGi, or both? A single representation would be the best. Will maven module versions be reflected in the OSGi bundle versions?

The major OSGi-challenge is not the technology, rather than the governance of your modules and bundles. The problem is very similar to SOA. For most enterprise applications you will get only one variant of your business logic, or even UI - so you will end up with modules, which will probably never be replaced. Because of additional complexity - you will probably test and deliver the whole system at once. If you are building an IDE, platform or a server - governance, modularization and versioning are a major part of your problem domain / functional requirements. You will have to solve that anyway. It is far more likely, that someone will have to install a new driver to an application server, or even maintain different versions of the driver at the same time. IDEs without plugins are also extremely rare. Replacing an algorithm in a business application is far more uncommon - often even not allowed. Its just crazy to introduce a modularization solution and then not use it.


Published at DZone with permission of its author, adam bien.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Bruno Leroux replied on Tue, 2010/03/09 - 5:38am

Reza, your open-minded comments are very interesting. The main point you raised is that OSGi specification seems very complex : "To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments "

You're right that abstraction is needed and many people in the OSGi world understand that. A lot of work was done since 2007, you should really have a look at the Blueprint Services and the Entreprise OSGi specification. OSGi Core is a very solid fundation, that's why folks working on complex softwares choose it (Glassifh, Eclipse, WebSphere). To make OSGi usable for standard web applications, an abstraction layer was needed, OSGi Blueprint Services is that abstraction layer. It will be very easy to use for many java developpers because 'Blueprint services' is (almost) Spring IOC rebranded.

Reza Rahman replied on Tue, 2010/03/09 - 12:38pm in response to: Bruno Leroux


The trouble is, of course, that I don't really see IoC as a cure-all either :-). I'm not sure if an IoC based solution is even needed here but is yet another overkill/distraction item to solve the modularity/classloading problem that can have other, perhaps more elegant solutions (Maven is a good example that Adam and others pointed out)...

Ideally, what I'd like to see is "peaceful" aligment of Jigsaw, OSGi and Java EE. So something like Java SE->Jigsaw->OSGi->Java EE. The theory here, of course, is that the realigment would do the evolution OSGi/Jigsaw/Java EE needs to be truly compelling as a modular system...just food for thought...



Neil Bartlett replied on Tue, 2010/03/09 - 1:17pm in response to: Reza Rahman

Reza, I'm sorry but now I think you're just confused! Maven is a build tool, what we are talking about is runtime module systems. Of course Maven can be used to build modular OSGi applications and indeed a major focus of Maven 3 has been towards support for OSGi.

I admit I am not a big fan of Spring either... but what do you dislike about it? Is it the XML, or is it the concept of Dependency Injection (DI) generally? If DI generally then you are presumably also against the injection annotations in JEE 5+, opposed to CDI and JSF and JAX-RS and EJB3 and all the other JEE technologies which are using DI heavily these days. This would be odd because you seemed in earlier coments to be strongly in favour of JEE 6 and its new-found focus on developer productivity.

If it is the XML in Spring, or its specific flavour of DI, then perhaps you would like to choose from one of the other DI frameworks that are able to take advantage of OSGi and abstract away the low-level details? For example Guice springs to mind. Or you could look at some DI frameworks developed specifically for OSGi, such as Declarative Services (DS) or Apache iPOJO.

The peaceful alignment that you are looking for already exists for two of the technologies, i.e. OSGi and JEE. When Jigsaw is released then it will also fit in, but it will only be the module system for inside the JDK, and it will not be visible at the JEE level or in application code. OSGi will continue to work for applications after the release of Jigsaw, because Sun/Oracle have promised full backwards compatibility.

You will in the future see some nice Java language enhancements like the "module" access-level keyword. That keyword is being defined by JSR 294, not Jigsaw, and if the 294 Expert Group does its job properly it will be usable in OSGi applications also (it is a simply matter of ensuring that the Java compiler knows which classes are in which modules).

Reza Rahman replied on Tue, 2010/03/09 - 2:07pm in response to: Neil Bartlett


I think we are mostly in violent agreement here :-).

I don't personally have any pro-Jigsaw bias as I alluded to before. Without being too prescriptive, what I'd like to see is an aligment of OSGi with the Java SE 7 module system in the JDK (however that might look like in the very near future). That can only benefit OSGi the way I see it and will likely smooth out some of the integration problems. I also agree with you on the Maven point (my point there is that DI is not essential to modularity but a "side" focus and cannot solve all problems "magically"). Again, without being too prescriptive, I'd like to see OSGi adopt a DI model that is already in Java SE/Java EE (where DI is even needed vis-a-vis modularity concerns). That is likely to make an alignment with Java EE easier instead of introducing yet another DI model. After all, there are some good technical reasons behind the DI model in Java EE 6 (JSR 330 included).

I beg to differ that there is really aligment with Java EE and OSGi right now. There are patchwork models, not really a truly seamless one. In fact, that should and could be the major focus of Java SE, Java EE and OSGi in the very near future.

As I said, I do look forward to your analysis. We are doing a similar analysis internally for Resin so it would be good to see how things match up (or not).

Just for better context here is a blog entry from our team not too long ago: I resisted posting this earlier to keep the discussion open-ended, but it might help at this juncture. Keep in mind, this is written with the assumption that an alignment of Java SE 7 (Jigsaw being the likely vehicle for that in the JDK) and OSGi is unlikely - I hope that isn't really true.



Neil Bartlett replied on Tue, 2010/03/09 - 5:46pm in response to: Reza Rahman

I would argue that late binding of implementation instances to interfaces IS essential for modularity, and that some form of DI is probably the most elegant way to achieve late binding in the Java language.

Another way to achieve it is with lookups, and OSGi's low-level APIs are based on looking up implementations in a registry -- the OSGi Service Registry. However DI can be layered on top of lookups -- much like JEE where the injection model is in fact layered on top of JNDI, another lookup-based API. Remember that EJB2 programmers had to write lots of explicit JNDI lookup code all the time... in EJB3 the JNDI hasn't gone away, it's just hidden underneath a DI framework.

Java SE does not yet have a native DI or late binding model; the closest it has is JSR 330. That DI model can absolutely be layered on top of the OSGI Service Registry, since it is after all based on a fusion of Spring and Guice. The dominant DI model in Java EE appears to be CDI (aka Web Beans or JSR 299). That is a richer model than JSR330 and it will take more effort to adapt to Services, but I would be very surprised if it couldn't be done. Indeed I heard that some work towards OSGi integration was being done in Weld, the RI for JSR299.

Incidentally the only real challenge in adapting a DI framework to Services is to cope with the dynamics. OSGi Services can come and go in response to events such as unavailability of a database or installation of a new module. Most existing DI framework inject dependencies exactly once, at startup; they may not support subsequent "uninjection" and "reinjection" of those dependencies. This is why I am still a strong proponent of Declarative Services (DS), which is a DI framework that was designed from scratch for OSGi with fully dynamic capabilities.

Thanks for the link to your blog articles; you'll notice I already found them and commented on them a while ago :-)

Reza Rahman replied on Tue, 2010/03/09 - 6:03pm in response to: Neil Bartlett


Yes, I know you responded to Emil and Scott - thanks for that. As Emil pointed out, CDI is actually much better suited to re-injection than Spring and Guice are, just as casual examples. The real question for us honestly is whether the modularity solution in the next JDK release is good enough for most use-cases and whether we really need an OSGi container in addition that has a very easy API/meta-data. That's what hopefully you can provide some real, simple and practical guidance on.



Bruno Leroux replied on Wed, 2010/03/10 - 10:13am


 I too share your opinion on Spring :-)
But when I look around me I see that a majority of java projects uses the following combination : eclipse, maven, spring, hibernate and an application server or a web container (maybe i'm wrong and it's not a majority ?). So i think OSGi could be the right solution to bring modularity to the mass because :

- Eclipse has a great OSGi toolset.
- Maven leaders (Sonatype) are very serious about OSGi (Tycho).
- SpringSource has embraced OSGi and with the BluePrint Services Specification Spring, projects relying on Spring IoC could switch to OSGi in a comfortable way.
- Several application servers are based on OSGi and already allow OSGi bundles deployment.
- OSGi Entreprise specification will clarify integration of OSGi on application Server, it will also clarify how to use JPA with OSGi.

 So my point is not that OSGi is the only way to solve modularity challenge, but that is the right choice considering it's conceptual quality AND it's market acceptance. Until now using OSGi on the server side was not an easy path. But with this market acceptance the main question about OSGi could switch from "Why should we use OSGi for our project (as it doesn't really fit well with our tools and runtime plaform) ?" to "Why should we NOT use OSGi (as it is really well supported by the tools and platform we rely on) ?". 

(Rereading the discussion and my message, I understand that you are looking for strong technical and conceptual arguments to use OSGi and that my answer on market acceptance is not what you are looking for, sorry for that).




Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.