Enterprise OSGi Is Not Bloated OSGi



I’ve been watching with interest the work of the OSGi Enterprise Expert Group (EEG). It’s been a slow process, as any standardisation effort should be, but they now appear to be on the home straight and have started releasing deliverables. For example, there is an implementation of the Distributed OSGi draft specification available in the Apache CXF project, which Eric introduces in his post. I’m looking forward to trying it out.

But the reaction to Enterprise OSGi has not been universally positive, even from people who support core OSGi. For example here is one representative comment I saw on Twitter:

    So, now OSGi tries to be a distributed communication layer too. There’s even an rfc for transactions. Was a good lightweight thingy, too bad.

I really do understand where this comment is coming from. As a Java programmer watching the JVM turn from a lightweight platform into a bloated monstrosity, it’s natural to associate “more” with “worse”. Heavens, these days the JDK includes a database and comes with the sodding MSN Toolbar. But OSGi is not like the JDK. The comment above fundamentally misunderstands the nature of a modular platform, and makes me wonder if the commenter really knows anything at all about OSGi.

The distributed RFC, the transactions RFC and everything else form an optional layer above the core OSGi framework. That core is just as thin and lightweight as it ever was. There is absolutely no chance that enterprise features are going to find their way into the core framework such that you will no longer be able to use OSGi in embedded devices… in fact I believe that Peter Kriens would literally murder Eric Newcomer and the rest of the EEG before he allowed that to happen.

So I find it hard to stomach the negativity towards Enterprise OSGi, since it comes from simple ignorance. If you think that distribution and transactions are stupid, then just ignore Enterprise OSGi. If you prefer to implement distribution some other way, e.g. with REST, then go ahead. The absolute worst possible outcome from Enterprise OSGi is that a bunch of people wasted some (okay, a lot) of their time writing specs that nobody will use. That’s very unlikely, but even that would have been a useful learning exercise.

你可能感兴趣的:(jvm,jdk,REST,osgi,twitter)