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