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

 

 

评论

17 楼 peterwei 2011-01-05  

还没看过这方面的东西，当扫盲了。

16 楼 leversss 2011-01-05  

OSGI复杂自然有它的道理，当然并不是所有的系统都要用OSGI，就算是要热插拔，也不是非得用OSGI。而且OSGI规范中明确说明，动态加载不是必须要实现的。也就是说，动态加载只是个附属功能，绝对不是核心。
让一个产品发展到一定规模以后，它的复杂度就会增加，各种系统间依赖关系错综复杂，这些复杂的关系中还伴随着各个模块的版本造成系统混乱，这个时候，用OSGI，才会发现它好处。一个技术，你需要真正在实际需求中使用它，才能发现它的魅力。
有句话大大的不妥:"OSGI立足于单个JVM,大规模java应用不需要它" 

15 楼 carydeepbreathing 2010-11-17  

tedeyang 写道

liaoxw 写道

我已经在及时通讯服务器中应用了OSGi，已经有一年多时间，用OSGi先要有系统分析要够清晰，开发和测试可以用其实方面来补充，

是为了不重启服务吗?

显然,osgi 热插拔是它的一大性啊，同意上面的说的，OSGI 运用的好坏取决于你对系统的分析的程度

14 楼 tedeyang 2010-11-02  

liaoxw 写道

我已经在及时通讯服务器中应用了OSGi，已经有一年多时间，用OSGi先要有系统分析要够清晰，开发和测试可以用其实方面来补充，

是为了不重启服务吗?

13 楼 liaoxw 2010-10-18  

我已经在及时通讯服务器中应用了OSGi，已经有一年多时间，用OSGi先要有系统分析要够清晰，开发和测试可以用其实方面来补充，

12 楼 hyhongyong 2010-10-08  

目前正在使用osgi构建一系列的产品基础
只能说osgi技术还不是特别成熟，特别是开发和测试效率确实要低一些
好不好，用用才知道

11 楼 snow8261 2010-10-08  

osgi技术感觉比较鸡肋。

10 楼 flysheet 2010-10-08  

<div class="quote_title">tedeyang 写道</div>
<div class="quote_div">
<p>国庆假期有点了空闲,得以有时间搞点新东西.</p>
<p>这几天把OSGI好好地考察了一下,因为年初Spring DM Server被SpringSource捐献给Eclipse基金会,最近在spring主页上看到Virgo项目的踪迹,我才后知后觉.</p>
<p>这其实意味着Spring对OSGI进行研究和探索的终结:<strong>OSGI还无法成为企业级JAVA的主流</strong>
,曙光尚远,让开源社区去解决吧.</p>
<p> </p>
<p> </p>
<p><strong>Spring的blog</strong>
: http://blog.springsource.com/2010/01/12/dm-server-project-moves-to-eclipse-org/</p>
<p><strong>Theserverside讨论</strong>
: http://www.theserverside.com/discussions/thread.tss?thread_id=59183</p>
<p>这里的争论非常多,大部分都对OSGI持否定态度,认为是下一个Corba,EJB1\2,DCE之流,太复杂.IBM的websphere小组来也露了露脸(被后面的人k),jdon的老彭也来贴link!</p>
<p>也有一些人在实践OSGI,并持很认可的态度.</p>
<p>公认的是:OSGI的学习曲线非常陡峭!</p>
<p> </p>
<p>对我来说OSGI这个名词出现已经很久了,原先在99bill工作时,他们已经开始动态模块的探索,在项目拆分上有意识地向这此靠拢.从那时候起我开始注意OSGI能不能实际应用.经过一段时间的阅读和理解,我觉得OSGI有以下特点:</p>
<p>1,动态,通过Activator接口实现LifeCycle管理.</p>
<p>2,模块,通过bundle和独立的classloader实现类隔离,用export,service,share实现模块间共享.</p>
<p>3,依赖,处理类库依赖.</p>
<p>4,管理,提供模块的管理能力.</p>
<p>5,单JVM,这个很重要,却没人提到.</p>
<p> </p>
<p>我归纳OSGI的作用是:在单个JVM上共存多个能热切换的module,实现application的模块化.</p>
<p>这决定了OSGI适合干什么呢?就是像eclipse这种应用:单机应用,非分布式,内部设计精耕细作,模块化插件化需求迫切,软件生命周期长.</p>
<p>OSGI想要解决的问题其实在各个领域都有解决方案,尤其在互联网行业,目前正处于分布式时代,通过ESB,SOA,http,socket rpc进行系统架构是行之有效的大规模集成方案,模块的粒度是服务器,既能满足扩展性需求,也能满足热插拔模块化(譬如切换JDNI,Queue,DNS,IP...等等),这些层次OSGI无能为力.</p>
<p>OSGI立足于单个JVM,大规模java应用不需要它,小规模开发呢?太繁了!处理多个模块的规划,依赖和启动顺序就需要个架构师.</p>
<p>两头不着落,在目前的时代,OSGI是尴尬的,它注定不是时代风向标,但确实是构建模块化软件体系的指导思想,即便是设计分布式应用也有很强的借鉴意义.</p>
<p> </p>
<p>今天是抗美援朝战争爆发60周年,我们接着解放思想,</p>
<p>跳出Java的框框,哪里需要什么OSGI,script language才是天然的热插拔王者...呵呵,做网站,还是得php之流.</p>
<p> </p>
<p> </p>
</div>
<p>    最近也在考虑学习这个东西，出于开发某个应用的需要</p>

9 楼 kkndone 2010-10-08  

侵入性太强，注定曲高和寡

8 楼 tedeyang 2010-10-08  

zhu_chen001 写道

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

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

7 楼 ray_linn 2010-10-08  

zhu_chen001 写道

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

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

6 楼 zhu_chen001 2010-10-08  

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

5 楼 bonny 2010-10-08  

06年的时候接触 感触和

phz50 写道

引用

OSGI的学习曲线非常陡峭

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

一样  就放弃了

4 楼 cuiran 2010-10-08  

元旦的时候开始学习，主要是osgi消息服务。

3 楼 傅庆岩 2010-10-08  

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

2 楼 mercyblitz 2010-10-03  

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

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

1 楼 phz50 2010-10-03  

引用

OSGI的学习曲线非常陡峭

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