About complexity, modularity and OSGi
Today I followed the link from this tweet:
“@nbartlett New blog post: No Solution for Complexity? njbartlett.name/2013/02/04/no-… #OSGi”
— Raymond Augé (@rotty3000) February 6, 2013
which leads to a this article. I read it quickly on my cell phone and got the following impression “The solution for Complexity is modularity. The way you properly do modularity is OSGi. So OSGi is the solution for complexity!”
Without thinking too much I responded:
@rotty3000 As much as I like #OSGi, I don't like articles that suggest it's the universal solution to all complexity issues.
— Milen Dyankov (@milendyankov) February 6, 2013
Which caused an immediate reaction:
@milendyankov I didn't suggest that at all /cc @rotty3000
— Neil Bartlett (@nbartlett) February 6, 2013
We exchanged a few more tweets but as Twitter is not the best platform for explaining what one have in mind, I thought I’ll write it here.
Let me start by stating that now that I have read the article again, I must admit my first impression wasn’t exactly correct. I now understand the intention and generally agree with it. However the article takes a few shortcuts which I would like to argue with:
If only there were a way to create “firewalls” between different parts of a large system, so that we could be absolutely sure that the functionality within each firewall cannot break merely from adding new functionality outside it. Then we could know precisely the scope of any change, and test only the things that can potentially break rather than the entire universe.
This would be true given than all the “firewalls” are completely independent of each other. Something I have never seen so far in any of the complex systems I’ve been working on in the last 10 years. And even if it was the case, you will need to take care of the “glue code”, provide communication interfaces resistible to changes, ensure data consistency between modules, …
I mean, think about SOA, the most modular approach I can think of. Can you “be absolutely sure” that when you change one service it will not brake any other? What about changing the data model for example? What about missing service? My experience tells me there is no such thing as “absolutely sure”!</p> <p>Need more visual example? OK, think about setting up a network. Each switch, router, … is separate module placed in a rack, which in turn is also a module, … Does this reduces the complexity of your network? Yes? Well, think again:
Modularity is a good thing, no doubt about it, but only when it makes sense for particular project and is done right! Sometimes it does solve complexity issues but sometimes it just moves them to different layer. And it has it’s price.
Nevertheless there is one technology that is mature, well proven and has stood the test of time: OSGi.
. . .
Look it up, and perhaps you could save your bank from making headlines for all the wrong reasons.
Absolutely agree with the first part. However will it really save your bank? Many believe OSGi is way too complex by itself. If fact I think this (whether true or not) is the main reason why OSGi is still not as popular and widely used as I would like it to be. May be Neil is right:
@milendyankov And I believe those who find OSGi complex are mistaken about the true source of that complexity.
— Neil Bartlett (@nbartlett) February 6, 2013
but do the test yourself. Pick randomly 10 or 20 average developers and ask them to explain to you how Java class loading works. Or at least simply ask what is causing this message:
Exception in thread "main" java.lang.ClassCastException: com.my.company.MyClass cannot be cast to com.my.company.MyClass</code>
and see how many correct answers you get (in case you don’t know read this). Got many correct answers? Good for you, you have some really good developers around. Now try to ask the same but in context of JBoss, Glassfish, WebSphere, … It becomes more complex right? Why?Among the other things, because it is modular. Jars, wars, ears, deployment contexts, … Will OSGi reduce this complexity and save your bank? Well, it may or may not, depends on what your use case is.
Don’t get me wrong, OSGi is a great platform!
It’s getting better and better with each release. And much easier to use (Bndtools, iPOJO, Blueprint, …) and much more user/administrator friendly (Karaf, Virgo, … ) then it used to be some years ago. And while it will not automatically solve all your modularity problems and reduce the complexity of your application it may indeed be very helpful.