关于OSGI的观察和思考

国庆假期有点了空闲,得以有时间搞点新东西.

这几天把OSGI好好地考察了一下,因为年初Spring DM Server被SpringSource捐献给Eclipse基金会,最近在spring主页上看到Virgo项目的踪迹,我才后知后觉.

这其实意味着Spring对OSGI进行研究和探索的终结:OSGI还无法成为企业级JAVA的主流 ,曙光尚远,让开源社区去解决吧.

 

 

Spring的blog : http://blog.springsource.com/2010/01/12/dm-server-project-moves-to-eclipse-org/

Theserverside讨论 : http://www.theserverside.com/discussions/thread.tss?thread_id=59183

这里的争论非常多,大部分都对OSGI持否定态度,认为是下一个Corba,EJB1\2,DCE之流,太复杂.IBM的websphere小组来也露了露脸(被后面的人k),jdon的老彭也来贴link :)!

也有一些人在实践OSGI,并持很认可的态度.

公认的是:OSGI的学习曲线非常陡峭!

 

对我来说OSGI这个名词出现已经很久了,原先在99bill工作时,他们已经开始动态模块的探索,在项目拆分上有意识地向这此靠拢.从那时候起我开始注意OSGI能不能实际应用.经过一段时间的阅读和理解,我觉得OSGI有以下特点:

1,动态,通过Activator接口实现LifeCycle管理.

2,模块,通过bundle和独立的classloader实现类隔离,用export,service,share实现模块间共享.

3,依赖,处理类库依赖.

4,管理,提供模块的管理能力.

5,单JVM,这个很重要,却没人提到.

 

我归纳OSGI的作用是:在单个JVM上共存多个能热切换的module,实现application的模块化.

这决定了OSGI适合干什么呢?就是像eclipse这种应用:单机应用,非分布式,内部设计精耕细作,模块化插件化需求迫切,软件生命周期长.

OSGI想要解决的问题其实在各个领域都有解决方案,尤其在互联网行业,目前正处于分布式时代,通过ESB,SOA,http,socket rpc进行系统架构是行之有效的大规模集成方案,模块的粒度是服务器,既能满足扩展性需求,也能满足热插拔模块化(譬如切换JDNI,Queue,DNS,IP...等等),这些层次OSGI无能为力.

OSGI立足于单个JVM,大规模java应用不需要它,小规模开发呢?太繁了!处理多个模块的规划,依赖和启动顺序就需要个架构师.

两头不着落,在目前的时代,OSGI是尴尬的,它注定不是时代风向标,但确实是构建模块化软件体系的指导思想,即便是设计分布式应用也有很强的借鉴意义.

 

今天是抗美援朝战争爆发60周年,我们接着解放思想,

跳出Java的框框,哪里需要什么OSGI,script language才是天然的热插拔王者...呵呵,做网站,还是得php之流.