How To Kill An OSGi Project - With 10 Questio...

How To Kill An OSGi Project - With 10 Questions

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?

[See also "Real World Java EE Patterns, Rethinking Best Practices" book, Page 253, (Premature Encapsulation Is the Root of All Evil) for more in-depth discussion]

Posted at 10:28AM Mar 08, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices  |  Comments[12]

[my tweets]  Rss My book: Real World Java EE - Rethinking Best Practices

"it is right now (future may change it) the only viable way to split your application into modules with well-defined dependencies"

I disagree. Another approach is using IOC and enforce IOC in your build process.

Posted by phil swenson on March 08, 2010 at 04:19 PM CET #

Hi Phil,

I'm glad, that you only disagree with the introduction to this post :-)

Enforcing IoC during the build process may be tricky. In case modularization is really needed, I would rather try to combine OSGi with maven right now.

Funny: although modularization is beneficial for decoupling of source artifacts, we sometimes deployed a modular project with: "jar-with-dependencies" maven assembly configuration. We even delivered JVM with the deployment - just to minimize possible side-effects in critical projects.

Thanks for your comment!,

adam

Posted by Adam Bien on March 08, 2010 at 07:10 PM CET #

Hi Adam,

it is funny to read that even Java savvy people have problems wrapping their head around the concepts of OSGi. It is true that it doesn't solve all your problems, but it makes the management and the focus on the real ones easier. I also believe that OSGi is promoted for the wrong reasons. Hot plugability for one is really hard to achieve and not always desired, especially with respect to testing, no doubt about it. What I think is most valuable is the enforcement of modularity. Now you can't cheat and violate the rules of module contracts (well, you can, but it gets really hard compared to plain Java). Except for points not relevant in my opinion like hot replacement f.i., we found a way to either adapt our workflow or use tools on top of OSGi to deliver high quality products or even just modules that can easily be used or integrated. This works for us in embedded, as well as enterprise scenarios. So, I guess at least for us the reality proves that it does in fact work. ;-) I admit, it is not easy to get started, but it certainly is worth the effort. Of course, nothing is perfect and I see a lot of potential for improvement. Anyway, thanks for sharing your impression. It's always interesting to see what people struggle with when being faced with new paradigms.

Cheers,
Mirko

Posted by Mirko Jahn on March 09, 2010 at 02:18 AM CET #

Frankly, we've just included OSGi for two very simple reasons:
1) It's actually pretty easy and integrates well with the Maven build process
and
2) It means that the plugins (yes we have to support plugins from other parties) don't have to track the versions of all the libraries that we use but don't expose.

Sure, we could roll our own simpler solution, but "rolling our own" would be a heck of a lot harder than just putting in an incantation to the OSGi fairies to do it all for us. (And it gives us better documentation, IDE integration, fabulous tools, and a big community to support people having difficulties.)

Posted by William Billingsley on March 09, 2010 at 07:32 AM CET #

(I realise in the previous comment, the phrase "incantation to the OSGi fairies" sounds rather cavalier. The point is that to our plug-in writers it really is that simple. We happen to know what goes on inside OSGi pretty well, but we don't expect everyone we work with to have to.)

Posted by William Billingsley on March 09, 2010 at 07:37 AM CET #

The question behind OSGi and modularity in general is not about technical issues, It's all about the famous "Time to market".

You cannot be fast If you work on you entire system all the time (unless you have a very small Information System).

Now here is my answers on different points : For points 1, 2, 3, 4, 5 the answer is clear : You have to handle backward compatibility as any integrated system does.
Please read this excellent article talking about Backward compatibilty and versionning policy :http://www.osgi.org/blog/2010/01/backward-compatibility.html.

For point 7 and 8, my company found p2 better than their distribution system and took It for RCP deployments : It just works fine.

For point 10. I highly recommend the use of maven Tycho which takes the best of both (dependencies relies on manifest files).

Regards.

Posted by pascal leclercq on March 09, 2010 at 12:15 PM CET #

Hi Adam,

I am interested in point 9 JPA.

If I have a module with JPA entities, how can I deploy this module in different versions if the data base schema must be updated. E.g. the new version gets additional properties.
I see only two solutions, using different schemas, which means different data for both versions or you must limit your change to optional additional properties.

Any other suggestions?

Thanks for your blog
Kai

Posted by Kai Prünte on March 09, 2010 at 01:05 PM CET #

Some of the questions listed above may actually kill an OSGi-based project when the business case for using OSGi is not well-grounded. However, some other questions could be really valuable for OSGi-based and even non-OSGi-based projects. For instance, I don't think that most projects have really thought about a stable technical versioning scheme. OSGi forces us to consider backward- and forward-compatibility and how we support such compability in the future by using well-defined versions and version ranges in intermodular relationships (involving dependencies to the base products).

If a software-architect is about to design an OSGi-based application, the architect has to ask how the degrees of freedom provided by OSGi must be restricted, depending on the project's context.
The architect may ask questions such as:
-How does the component model of OSGi and Eclipse (involving Features) map to our current component model?
-How does the versioning scheme of OSGi match our current versioning scheme? Are they compatible or do we need another versioning scheme with major, minor and service version?
-What is our strategy for initial deployments, updates and patches? Depending on that, we have to set rules for upper and lower bounds of version ranges. Otherwise, it may be impossible to roll out a simple patch.

OSGi because it forces us to consider design-aspects such as modularity, life-cycle management and versioning (which is not a bad thing ;-). On the other hand, I don't think that dynamicity is really a major driver for OSGi. Quite the contrary, enterprise environments have to be stable and deterministic.

Posted by Stefan Bohm on March 09, 2010 at 01:52 PM CET #

@Mirko,

"it is funny to read that even Java savvy people have problems wrapping their head around the concepts of OSGi"

Yes - I really question everything, before I introduce it to my project.
Also OSGi,

thanks!,

adam

Posted by Adam Bien on March 09, 2010 at 03:30 PM CET #

I prefer the NetBeans module system to OSGi. OSGi is not the only viable modular system for Java!

Posted by Antonio on March 09, 2010 at 04:49 PM CET #

Perhaps JEE packaging strategy with ears is a better solution :-D ?! I don't think so. I feel very well with the OSGi style, however it is not so handy for a rookie

Posted by openwms on March 11, 2010 at 03:54 AM CET #

@Openwms,

For the old style JavaEE packaging the same questions have to be asked. Sometimes I see tons of ejb-jars - without any explicit requirement. It caused just bloat and increased management efforts without any benefit.
But: the WAR-deployment is also sufficient for 80% of all cases. Your ejb-jars are included within the WAR and loaded with a single classloader - and most of the problems are gone.

Just YAGNI, DRY and KISS for everything.

thanks for your comment!,

adam

Posted by