The TSS thread on Virgo and whether or not OSGi is ready for mainstream enterprise application development contains some misconceptions.
Firstly, that SpringSource is somehow not involved in the OSGi standards process.
That couldn't be further from the truth. Recently we've led the standardisation of Spring DM into the blueprint service specification and reference implementation while IBM provided the compliance tests. We are developing the reference implementation of the OSGi web container while IBM wrote the specification and are providing the compliance tests. Then, as we look to the future, we are leading two, and involved in other, new specifications targeted at R4.3.
Secondly, it is easy to get the impression that other vendors, such as IBM and Oracle, are about to solve the adoption problem.
I certainly hope they do, but, at least in the case of IBM's WebSphere Application Server OSGi alpha, their programming models seem very similar to that of dm Server and their development and build tools, where the real adoption issues seem to be, do not seem to be particularly advanced.
Perhaps IBM's large customer base and marketing machine will encourage developers to jump the necessary hurdles. But the tricky thing about a product like WAS is that, after the alpha code has been rolled into the main product, it will be very hard to measure real usage. The only real evidence will be customer testimonials and APAR (i.e. external defect) rates against the OSGi features, which IBM typically do not publish.
Let's see how Virgo gets on. At least the adoption should be easier to measure as users will almost certainly be using it for its OSGi features.
I think that the wording of Adrian's announcement blog post inadvertently provided some ammunition to those who are declaring OSGi either "too complex" or "not ready for the enterprise".
ReplyDeleteNow, I think I understand what Adrian was saying: simply that OSGi carries a short-term cost. That's something we can all agree on. He also intended to assert that dm Server (Eclipse Virgo) provides tools and runtime support to ease the transition into OSGi. Unfortunately many people have seized upon the first part of his statement -- i.e. that OSGi is complex -- and rather than looking to Virgo for help, have instead resolved not to bother with OSGi at all. This is sad, and I'm sure it's not what he intended.
Another thing which I'd like to see you and/or Adrian robustly debunk is the idea that SpringSource is now "dumping" the dm Server product into open source, on the basis that you have had limited commercial success with it so far. I even saw one blogger suggest that SpringSource has switched away from OSGi as a blow against Glassfish and JBoss, whom you brilliant "tricked" into adopting OSGi ;-)
If you're writing a relatively simple WAR file, then it's hard to extract sufficient value from adopting OSGi to justify the short-term cost.
ReplyDeleteOTOH if you're writing a complex app or an app with some sophisticated infrastructure code, then OSGi's benefits are likely to outweigh the costs.
In between, the decision is harder and factors such as developer skill level and the state of any legacy code and its build system could make all the difference.
Unfortunately, it's not uncommon for software teams to be on the lookout for a "silver bullet", so we are trying to be responsible and not over-sell OSGi. Detractors will latch on to any guarded statements, but that's life.
As for SpringSource dumping dm Server, we plan to invest in it for the foreseeable future and, if community adoption goes the way we would like, to increase that investment in the future.