osgi的企业级开发的一些经验

 

前面看了论坛里面关于osgi的一些讨论。讨论挺火热的，发表一下自己的见解。

 

 

笔者从08年开始使用osgi。早期在终端开发，(原公司网址hotye.com)。使用osgi对各个硬件模块、业务模块、服务模块进行分离。

 

osgi终端应用 

在终端项目的开发。osgi是绝对占优势的。

 

如:

使用 模拟的密码键盘.jar 这个bundle,在运行时即可进行系统调试。

 

 

 

osgi后台系统

09年初开始应用在后台系统。将不同业务拆分、不同通信模块拆分。

 

接受广东省500台终端发送过来的请求。现日均处理请求量30w以上。

 

在多业务的平台上，使用osgi是有优势的。

 

后来离开公司通过blog也了解到，在某些外部公共的jar在多classloader下会出现一些问题。需要自行解决。

 

在后台业务系统应用osgi。可能出现的问题出在第三方jar的class无法替代osgi同名的class,这需要自行去处理。

 

 

 

淘宝的osgi

 

淘宝网内部分布式调用框架hsf 4.0从jboss微内核转到osgi平台。

 

其架构师毕玄与另外一同事出书《OSGi原理与最佳实践》，电子版本infoq有得下载，不过电子版本我看了一下是应用为主。想深入理解的还是看看osgi的中文文档好点。下载地址见附件。

 

 

 

结语

国内使用osgi的公司可能远远超过我们的预期。

 

套用林昊的话：OSGi规范对于模块的物理隔离、模块的交互、多版本这些方面都有了非常完善的机制，并且也得到了现在几乎所有的App Server厂商或开源社区的认可

 

而是否使用osgi,是否模块化、模块动态化？

 

没有使用过的没有理由一定要使用。

 

对于使用惯了的会认为没有模块化、模块动态化的系统很不方便。

 

 

 

osgi规范中

一些可能有用的记录

 

MANIFEST.MF：

 

Bundle-UpdateLocation: http://www.acme.com/Firewall/bundle.jar

描述bundle的更新地址。如果bundle需要更新，则使用这个地址进行更新。

 

Import-Package: org.osgi.util.tracker,org.osgi.service.io;version=1.4

声明bundle导入的包。参考导入包一节。

 

DynamicImport-Package: com.acme.plugin.*

包含了一个逗号分隔的动态导入包清单。参考动态导入包。

 

Export-Package: org.osgi.util.tracker;version=1.3

描述导出包声明。参考导出包。

 

 

 

 

最常见的版本兼容原则如下：

• 主版本号（major）：不兼容的更新

• 副版本号（minor）：向后兼容的更新

• 小版本号（micro）：不影响接口的更新。例如，修正了一个错误。

 

 

osgi原理：

 

每一个bundle只会有一个单独的类加载器，类加载器形成了一个类加载的代理网络结构

 

 

类加载器可以加载类和资源，加载途径有：

• 启动类路径：启动类路径中有一个java.*的包以及它实现的包。

• 框架类路径：在框架中通常有一个单独的类加载器，加载框架实现的类和关键的服务接口类。

• Bundle类空间：bundle的类空间由和bundle相关的JAR文件组成，以及其他和bundle紧密相关的JAR文件，比如bundle片断（参考bundle片断一节）

类空间是指一个给定的bundle类加载器可以访问到的所有的类。因此，一个指定bundle的类空间来自：

• 父类加载器（通常是来自启动类路径的java.*包中的）

• 导入的包

• 必须的bundle

• Bundle类路径（私有包）

• 附加的片断

类空间必须是一致的，也就是说不能存在相同全名的两个类（为了防止类声明错误）。但是，在OSGi框架中，不同的类空间可以存在同名的类。在模块层，支持不同版本的类加载到相同的虚拟机中。

 

osgi中类加载机制：

 

类加载器必须通过利用在解析过程中建立的连接(wire)来找到适当的exporter。

如果一个类没有在导入包中找到，那么根据在附加的manifest中的定义在附加的空间进行查找。

 

全部java.*开头的都会在启动类加载器中加载，其他必须通过启动类加载器加载的包可以通过在系统属性中指定：

org.osgi.framework.bootdelegation = package-name,package-name*

 

类查找流程：

 

 

 

生命周期//todo

服务层//todo

 

 

 

多谢提供这么好的资料。

从楼主的描述可以看出，使用OSGi实现的应用里完全没有传统J2EE项目的影子，终端开发，多业务平台，分布式调用框架。等等。

为什么没有做应用系统的同志采用OSGi呢？说白了还不是因为技术难度高，系统也没有必要分模块，需求不稳定，没有成熟的基础开发平台。

最后的结论应该很明显，做业务系统有没有采用OSGi划分模块的必要呢？想快速就采用jdbc+jsp或者ssh之类的组合不就行了，要是需求变动就用人顶。

反过来OSGi实际上能给项目带来什么好处？分模块，接口设计？这些都是技术上的，说得难听点儿就是在玩技术，如果业务上确实没有模块动态加载的需求，何必去趟这片浑水呢？

最后还是多嘴提个疑问：“OSGi有没有可能搞出一个像ssh之类的快速开发框架呢？让不了解OSGi的开发人员也能够在此平台上进行开发，调试，测试，部署等工作。”

    我感觉osgi是一种致力于解决“复杂”问题的方案，对于复杂度不高的场合，完全没有必要为osgi而osgi。

    而且osgi前期复杂度比较高，入门门槛高，以传统的开发方式和思维都有巨大差异，普及难度远比ssh高的多。

多版本的特性在企业应用还是很可用的。如
交易系统服务1.0
交易系统服务1.5
这样，两个服务就可以并存，并且新系统直接引用1.5的服务。除问题了还可以无缝回到1.0系统。

呵呵。同样一份文档,放在09总结就没人下载，放在这一天就51个下载了。

呵呵。真的是价值存在于地位啊~~~~

对于传统的基于SSH或者是JDBC/JSP的J2EE应用应用系统使用osgi开发，真的是还没见到。所以现在虽然网上关于osgi的资料有，但是还是很难能够看出它能够为我们的Web系统的设计、开发、维护、拓展带来哪些好的东西！

其实。。。osgi解决了任何实际问题吗？

这个也一直都有争论。

有多少项目真的要用到hot swap jars...

其实等java从Languange level support component后（据说马上的事情了）， osgi就丧失了存在的意义。。。

同楼上几位大侠所闻，一年前开始折腾OSGi,但是发现在公司应用中很难有发挥的余地，就又荒废了。

其实。。。java解决了任何实际问题吗？

这个也一直都有争论。

有多少项目真的要用到write once run anywhere...

其实等.net从System level support language后（据说马上的事情了）， java就丧失了存在的意义。。。

使用OSGI并不是所有特性都需要用上。
我们现正在使用的后台交易系统中，使用了其bundle的独立性，保证了系统对某些业务bundle的随时去除和替换的低风险。
在各个bundle的升级中，无需停止正在运行的系统，可轻易进行refresh升级，保证了其他业务不受升级的业务影响，且在白天也可对我们的系统进行升级。
为了使用一样东西而去使用，和令一样东西为我们服务，这是不同角度的想法。