OSGi ,有人用过吗?

OSGi 近来似乎很流行,有人用过吗,说说经验体会,好象跟SPRING一起用。我初步了解了下其用法,好象是一种SOA的思想。

OSGI可实现即将即用 热部署,包括分布式环境,除了这个,你就会觉得OSGI象个套子。

OSGI跟踪管理服务是很复杂,即使有Spring DM帮忙,还是要启动OSGi runtime and install and start the bundles。

老外有一篇使用的心得:OSGI可能是下一个EJB,对OSGI又爱又恨:
http://peterrietzler.blogspot.com/2008/12/is-osgi-going-to-become-next-ejb-bubble.html

因这个网址被查封,转帖英文如下:

A few weeks ago I spotted an article that stated OSGi as "the next big thing after Spring". Actually, there are a whole bunch of articles, blogs etc... out there in the wild - all praising OSGi as one of the next "big things" that will reach many sectors in the Java space. I don't doubt this and I do admit that OSGi solves many problems and supports top notch architectural models such as high modularization and micro services. However, on the other side - after using OSGi for a couple of years and see how it performs (in the meaning of development performance) in different areas I really have doubts about OSGi.

Here are some things I love and hate about OSGi:

The concept of creating a system out of even hundred of typically pretty small bundles is very good. The really good thing about bundles in OSGi is that they have defined borders - not only in the sense of dependencies but also in the sense of runtime. Each bundle can serve as a micro application, having it's own lifecycle, having it's own citizens and each bundle can carefully decide which objects to expose to the outside world. Carefully adopted, this leads to a system with loose coupling and a high probability for reuse. However, at the same time the lifecycle model of OSGi makes life complicated. Actually, tracking services and managing all the aspects of what to do when services come and go is nasty (I've seen systems that had tried to manage these things with pretty large state machines in their bundle activators ... this is boiler plate that no one wants to write!) - Luckily, there's Spring DM out there that helps us manage these things. To be honest - I'd never even think about starting an OSGi project without using Spring DM. Altough Spring DM greatly reduced the complexity of bundle setup, it's still complicated. I still need to start the OSGi runtime and install and start the bundles - and I have to take care that all other bundles that I need are installed and started too ...

[该贴被admin于2009-07-02 17:03修改过]

I personally think that we - as developers - have to enforce constraints on ourselves! We have to automatically check the defined constraints and let the build process fail if we e.g. accessed some classes we were not meant to access. OSGi's versioning concept (as a side effect ...) makes a first step of bringing the enforcement of architectural constraints to the developer's daily life by definining export and import packages ... and introduces a completely new dimension of problems! OSGi resolves versioning issues at runtime by giving each bundle it's own class loader and let that class loader see exactly the classes in the versions it depends on. Sounds neat ? Yes it is - and you will curse it! This leads to a really new dimension of problems, because it really changes the way your environment works. Your code passes all your unit tests, but once you start it in an OSGi runtime it crashes; Libraries crash because the enhance their classes at runtime; Singletons designed as static objects get created more than once; The story continues ... You typically end up in a situation where you constantly tweak your modules build specifications (that creates your manifest) and spread absolutely counter-intuitive dependencies across your whole system. Spring DM also addressed this topic - by adding some directives to your services and tweaking around with the class loaders ... and you still need to tweak and spread dependencies. I'm shivering at the thought that I need this workaround to even get started ...

Especially that class loading hell leads to a new dimension of problems. You will quickly notice that you cannot go on without a strong and automated integration testing suite that incorporates OSGi (another thing that Spring DM supports).

Now - what's my conclusion about all that stuff. First of all - before considering OSGi I would really check if I have the ultimate requirement to exchange bundles at runtime without shutting down the system - and even in this case I would really revisit these requirements and see if I can limit them to a corner where I could use other techniques for dynamically loading modules at runtime. There are alternatives out there fostering the architectural principles (e.g. you could use an IOC container, use independent container instances to enforce module independence, do constraint checking at build time, etc...) - most of these things are much closer to the KISS principle, avoid all the additional boiler plate code and build configuration - and therefore allow you to stay more agile.

I almost forgot the title :o) There's another technology out there with pretty the same characteristics (in terms of things being complicated): EJB. Spring is propably the most popular example of what can happen when a technology is way too complicated and makes life hard. Maybe we will experience the same thing with OSGi in in the next years ? I cannot say ... however, if this is the case, then there is a certain irony in that SpringSource now heavily supports OSGi :o)

我们为什么需要分布式OSGi
http://www.infoq.com/cn/articles/newcomer-distributed-osgi


分布式OSGI其实已经在newton infiniflow中已经实现,2009年中标准出炉,这就越来越像EJB了。

不过因为它和EJB一样,是给POJO上的一个套子,这个套子是不是合适,看来用了EJB套子的人再换这个新套子试验看看。

正因为这种套子感觉,OSGI支持者就疯狂劝说SUN在其JDK中加入OSGI,Java 7可能考虑加入OSGI,但不是完全的。

OSGI曾经在Spring DM Server和SUN的glassfish v3推出时,引起一段骚动,但是现在已经没有什么动静,难道Java领域现在只有靠冷饭热炒来制造一些热点吗?

我不否定OSGi在动态上有其特点,但是从设计角度来看,而这正是很多人推荐OSGI的原因,从分离关注角度,从透明性角度(带的套子再超薄透明,也是套子),OSGI要打折扣的。

另外,OSGI组件配置中指定输入包和输出包,这个配置相对于自动依赖注射auto wired,要显得有些弱智。

OSGI本身已经走向重量化,特别和SCA结合,简直是一个超级重量武器,和EJB有过之无不及,所以,我还是喜欢原来嵌入式设备上的OSGI,apache的felix用在服务器端就很好。

btw:我现在有一个机械判别组件或框架的重量和轻量的方法:核心组件jar包不要大于300K。

以上是个人意见,只供参考,不过现在我写这些,也许OSGI的fans们已经冷静许多。

关于Java 7模块系统(OSGI)
http://www.infoq.com/cn/articles/java7-module-system
[该贴被banq于2009-07-02 17:24修改过]