Thursday, April 16, 2009

The hype around OSGi

Reading Robert's very interesting blog entry OSGi: YAGNI , I can only agree with the author's view of OSGi.

OSGi makes a nice kernel if you want to build really modular applications, but how many real world systems really need this? I'd dare to say maybe 10% of them and certainly less than 20%. The remaining 80-90% will have little to benefit from a super modular design, although they will have to bear the overhead and cost of creating and maintaining an application according to OSGi rules.

Witness the success of dynamic languages and development environments where development speed is the ultimate goal. Those guys care less about packaging, isolation and hot-swapping of subsystems and more about getting their work done. As long as the containers are fast, recycling the whole application is simpler and safer in most cases.

People have been writing enterprise web applications for years, do you think packaging is really their primary concern or the offered standardized functionality, richness and relevance of APIs?

Don't get me wrong, a kernel based design is essential for runtime environments, or other truly dynamic designs. JBoss had a kernel since 2001 and I presume that for the other players an OSGi kernel makes sense, if you didn't have one in the first place and if you feel comfortable with tying up your server internals with this particular technology. We are also in the process of adding support for OSGi deployments, although this is not our #1 priority simply because our customers and users don't really ask for it.

But proposing that every other application needs to fit this particular design is just an effort to tie you up in elaborate development environments and runtimes that promise to alleviate the pain of complying to the new "standard". Even if that means you need 20 steps to run and deploy a simple hello world application.

Or else, how can you can possibly monetize tomcat? :-)


Eric Newcomer said...

Let's see - modular programming has been around for how long? 30 years? 40 years?

The benefits of modularity are pretty well understood by now.

The OSGi framework gives developers a good way to implement modular programming, and realize its benefits.

The benefits of modular programming apply closer to 100% than 10% of applications.

This blog entry directly contradicts established computer science. Hard to believe.

Dimitris Andreadis said...

@Eric, I am mostly talking about packaging, the need to be explicit (precise and correct) about your exports and imports.

An average working web application may have packaging inconsistencies and yet be useful enough.

Until tool support makes OSGi "invisible", those application have little to benefit.

Luxspes said...

Yes, who needs OSGi, after all, we would only want OSGi if, for example we wanted to have hot redeployment of SLSB and SFSB, but who wants that? nobody, it is as if it were the most voted (and most ignored) feature request in JBoss implementation of EJB 3.0. And certainly it is no reason to drop EJBs and switch to plain POJOs after all, no time is wasted during development waiting for the appserver and all the .jar dependencies to reload when you only changed a tiny little thing.

Oh, and about the success of dynamic languages, you are absolutely right, those guys care less about packaging, isolation and hot-swapping of subsystems and more about getting their work done. It is not like JavaScript is getting process isolation features before Java. And who cares about packaging and versioning, certainly not Microsoft,it is not like .NET has had a solution to classpath hell since 1.0...

Of course, since JavaRebel is free, we have nothing to envy about those dynamic languages that allow for reloading only what you have changed (and not all the dependencies around you).

Mmmm, I am getting the feeling someone is confused here... maybe its me...

Bill Burke said...


Our containers have always supported hot deployment, what we don't support across the board is *incremental* deployment where you change one EJB class and have that one component be redeployed (instead of the whole jar/war/ear).

Don't see how OSGi enables the ability for *incremental* hot-deployment. This much much more to do with the underlying component layer than the kernel itself.

@Eric: I've said this before: OSGi should be invisible to application developers, which is why, IMO, customers just don't really care much about it.

Eric Newcomer said...

Hi Bill,

Now that I am a customer, working for Credit Suisse, I can tell you for sure we do care very much!