OSGi技术预测: 未来几年60%的Java虚拟机上将部署OSGi

<meta content="text/html; charset=utf-8" http-equiv="CONTENT-TYPE"> <meta content="OpenOffice.org 2.0 (Linux)" name="GENERATOR"> <meta content="Ery Lee" name="AUTHOR"> <meta content="20061228;23093300" name="CREATED"> <meta content="Ery Lee" name="CHANGEDBY"> <meta content="20061229;11381300" name="CHANGED"> <style type="text/css"> </style> <p style='margin-bottom: 0cm;'>尽管我在一年前曾预测<font>OSGi</font>最终将部署在<font>60%</font>的<font>Java</font>虚拟机上，但<font>OSGi</font>的发展速度还是超出了我们的想象。一直认为<font>OSGi</font>规范是<font>Java</font>领域被埋没的一颗明珠，它优美的组件体系结构正是<font>Java</font>平台不可或缺的部分，应该直接纳入到<font>JDK</font>中。<br/> </p> <p style='margin-bottom: 0cm;'>众所周知，<font>Java</font>平台有庞大的开源框架、类库支持，但我们却一直停留在类与<font>API</font>层次的复用，一个较大的<font>Java</font>项目往往有大量的<font>Jar</font>包混乱的堆积在<font>classpath</font>下。所以<font>Java</font>领域迫切需要一个实现<strong>组件级复用</strong>的解决方案，将所有这些混乱不堪的类库与<font>API</font>以组件的形式发布，在统一的容器内组装协作，<font>OSGi</font>规范无疑是目前最为出色的候选者。</p> <p style='margin-bottom: 0cm;'><font>OSGi</font>的规范已经提出<font>5</font>、<font>6</font>年的时间，到现在被业界广泛认可，其发展过程很有趣。<font>OSGi</font>规范最初定位于嵌入式系统，如家电、汽车、手机、家庭网关，满足单一<font>Java</font>虚拟机上启动多个<font>Java</font>应用程序和动态从网络安装卸载应用程序的需求。但那时嵌入式<font>Java</font>虚拟机还不成熟，更不用提<font>OSGi</font>的应用，尽管有宝马等知名公司的应用，但一直没有在<font>Java</font>嵌入式领域获得广泛的应用。<br/> </p> <p style='margin-bottom: 0cm;'>随后的发展一定超出了<font>OSGi</font>委员会<font>(<a href='http://www.osgi.org/'>www.osgi.org</a>)</font>的想象，<font>OSGi</font>居然被<font>Eclipse</font>应用到了客户端。 <font>Eclipse</font>原本插件体系结构是一个基于<font>XML</font>的静态扩展结构，即扩展<font>(Extension)</font>与<font>(Extension Point)</font>，不知道当初基于什么样的考虑，<font>Eclipse</font>组织在<font>3.0</font>版本选择<font>OSGi</font>作为插件体系的内核，这样由<font>OSGi</font>负责插件体系架构中<font>ClassLoading</font>机制，由扩展与扩展点负责业务层面的扩展架构，这是一个很完美的结合。但我认为这实际上并不是<font>OSGi</font>的最佳实践，<font>Eclipse</font>原本的静态扩展架构限制了<font>OSGi</font>的动态性，也没有应用<font>OSGi</font>的服务层模型，而是大量基于单例<font>(Singleton) Plugin</font>调用协作，开发<font>RCP</font>客户端时，你会发现很少需要注册<font>OSGi</font>的服务，往往一个<font>Plugin</font>的入口类提供很多静态方法。当然，这也可能与<font>Eclipse</font>的延迟加载<font>(Lazy load)</font>机制有关。<br/> </p> <p style='margin-bottom: 0cm;'>尽管<font>Eclipse</font>不是<font>OSGi</font>的一个最佳实践，但随着<font>Eclipse</font>的成功，<font>OSGi</font>迅速普及与成熟，最终将<font>OSGi</font>推向它最擅长但一直被忽略的领域：<strong>企业级应用软件的服务端，纯插件体系架构的服务端！</strong><span style=''>目前，大量的服务端开源架构与商业产品向</span><font><span style=''>OSGi</span></font><span style=''>迁移，</span><font><span style=''>2007</span></font><span style=''>年将是</span><font><span style=''>OSGi</span></font><span style=''>服务端应用的开始。</span><br/> </p> <p style='margin-bottom: 0cm;'>随着<font>OSGi</font>在胖客户端<font>(RCP)</font>、服务端<font>(Server Side)</font>与嵌入式<font>Java</font>虚拟机上的广泛应用，相信未来几年内，<font>60%</font>的<font>Java</font>虚拟机上部署<font>OSGi</font>的目标并不是遥不可及。</p>

OSGi组织的最大投资商是IBM，Eclipse的发起人也是IBM，可想而知了～

好像Eclipse IDE就是OSGi的一个参考实现～ 其成功之后，IBM就把它应用到几乎关联所有的产品线上，动作还算够快，呵呵

个人对OSGi仅仅有过耳闻，并没有什么切身实践，所以说得不对的地方请多指正。

Eclipse对插件的管理在3.0和3.1的时候我觉得都不是非常好用，而现在的3.2和3.3已经有了很大的进步（方便了好多），也许正是托了OSGi技术的快速发展的福了吧。

随着Spring在中国的愈发风行，而对OSGi的支持是它现今的一个重要开拓领域，所以我想OSGi应该能够很快跨越中国技术人员历来对于“新技术”的心理障碍，从而得以较快地得到认同乃至支持。