I demand answers to save OSGi

Adam Biehn’s blog is quite an interesting read. But I almost missed a very interesting post there.
Why I almost missed it? Cause I am sick of all those pointless OSGi vs Jigsaw discussions.
After reading the title “How To Kill An OSGi Project – With 10 Questions” I almost skipped it, expecting another piece of flamebait.
Thankfully I read it and I have to admit: He got some good points there.
The set of questions is something each developer/architect should go through before getting started with modularization.

The only thing I don’t like about this article:
Why on earth formulate GENERAL modularization problems in a way to make them look like they were exclusive to OSGi? I know, objective is long lost in the whole modularity discussion, but come on.

So here is my 100% subjective take on his questions:

1. What is your versioning scheme for modules(bundles)? Do you care about minor versions, major versions etc?

This debate has been going on forever. I use major.minor.patch for version, something OSGi has been doing for ages, tons of open source projects do it and I never had any real problems with it. As long as nobody shows me REAL advantage of other versioning schemes I’ll keep using it.

2.  What’s 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? :-))

As soon as something is deployed to the external world it gets a branch.
Yes, the amount of branches you are ending up with is big.
When thinking about modularity this is something you can’t ignore as this adds significant project overhead.
Once again: I just don’t see why this is an OSGi problem. Every modularization system will introduce this problem. If you are not prepared to deal with it, don’t modularize.

3. How many versioned modules will be active at the same time in production?

Best case: 1

Worst case: ∞

App servers have been doing this for ages. They allow deployment of several application instances with different versions (Captain Obvious strikes again, I know). The key thing here is that vendors have been reinventing the wheel for this countless times.
OSGi (and other modularization frameworks) provide the means to handle these situations in a generic way.
Another scenario can be summed up in one word: Drivers.
A lot of time we need to provide connectivity something outside our world.
These things are constantly changing. Sometimes a firmware upgrade is enough to make a driver useless.
From a company point of view it is a valid thing to increase the major version, remove support for the old firmware and carry on with a clean bundle.
Nice move, the customers will just upgrade all their hardware to the new firmware and carry on using the new driver. How long can it possibly take to upgrade 200 RFID readers to the newest version … I think you understand the problem.

The capability of having the same thing deployed multiple times in different versions is something that won’t be needed for most enterprise apps. But it’s good to know that the functionality is out there. Just don’t think you are getting it for free.

4. How the system is going to be tested? Each module and all the combination of modules. Every version will increase the complexity significantly.

Unit testing just doesn’t cut it for a real modular system.
“Each module and the combination of modules”, I’d even add another part ” and all their versions”.
Looking back at my answer to question 2 the problem becomes apparent.
Over time it becomes utterly impossible to test all combinations. Writing Unit tests and testing them will actually start eating up more time as the development of the whole application.
My suggestion: Use “Design by Contract”
The main problem of modularity in Java is Javas inherent lack of true contracts. Interfaces are the weakest type of contracts in OO. I actually wouldn’t even call them contracts but suggestions, like traffic lights in New York.
To make a modular system more robust one needs to define real contracts and check if the bundle follows the previously defined contract.
The contracts need to cover both: exported services and api.
Get Contract4J or use some AspectJ and annotations to define the contracts. Combined with unit tests for each bundle this should give a lot better ratio of test
This isn’t a 100% solution and I fully agree that a lot more has to be done in the area of testing. But we are just now seeing how modularization technologies are getting into the mainstream and I guess there’s going to be a lot of development in that direction.
So far I think the combination contracts and unit testing is already a pretty good start.

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)?

Ok, here I just can’t give a generic answer as this strongly depends on the project you are doing and has to be decided on per project basis.

6. Do you really want to replace modules in running system? If it is a serverside system – what happens with in-flight transactions?

The question shouldn’t be if you want to, but if you have to. Sticking to the good all KISS principle should give you the right answer to this one. If you don’t need it, don’t use it. I needed it, I used it, I developed a strategy to deal with problematic scenarios, it worked. It’s not easy, but software architecture isn’t either.

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 :-))

Sorry, never had to deal with such a scenario. Skipping this one.

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.

Ok, so far you answered all questions in favor of modularity. Your customer loves it but REALLY wants to stick with his software distribution system without wanting to compromize. Cool, you just killed the project.
How often did you have to deal with a customer who desperately wanted to stick with JDK 1.2 or a good old Oracle 8.x installation?
That’s just how it goes …

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.

I guess you know my answer: Design by Contract (see question 4).
With friend relations I guess he means Bundle-BuddyPolicy and I can’t see anything wrong with that. I avoid it if I can but sometimes it’s the best solution for the problem at hand.

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?

Maven … OSGi … Maven
Maven module versions should reflect the bundle version. The problem is that mostly you will be doing it the other way round as people will often create the MANIFEST.MF from the pom.
My wish: OSGi should be the canonical representation.
The reality: Maven module versions are the canoncial representation.
With Tycho hopefully getting a stable release within the next month and Sigil finalizing their transition to Felix things might finally start changing.

So, here you go. A completely subjective list of answers.
I had a little rant prepared about what I don’t like about his way of formulating the questions.
In the end I am just sick about pointless discussions.
Just get me some modularity into the JDK so I can kick out libraries I don’t need. Anything above will be OSGi. A least that’s what everybody else seems to do.

Advertisement