关于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之流.

 

 

同意，曾经学过一段时间，感觉OSGI有点复杂，且没看到实质性的好处。

去年就研究过，发现它不太方便。

ClassLoader的问题急需解决，期待JDK7的带来啊！

osgi模块化的思想是主流 但是他的那些优点，热部署等，其实并不是在实际应用中急需解决 osgi 道远。

06年的时候接触 感触和一样  就放弃了

没有同路人啊，开发起来感觉OSGi很容易提高软件内在的质量，至于复杂性吗，的确很高，上手困难。但是随着规范的深入，感觉未来的前景还是在OSGi

一个很复杂的东西很难提高软件的质量，只怕会导入更多的问题。。。。

感兴趣
你们通过什么方式提高了软件的内在质量？
是不得不拆分接口和实现，还是必须的模块化和生命周期设计？
这些好处不用OSGI也能得到啊。

    最近也在考虑学习这个东西，出于开发某个应用的需要

osgi技术感觉比较鸡肋。