OSGI热部署、动态化的优缺点

作者在某厂从事opendaylight-sdn的研究。opendaylight是基于OSGI架构的。所以最近一直在研究OSGI的优势。有兴趣的可以一起交流。

所有做Java服务器的都知道spring的两大优势：IOC与AOP。自从OSGI借鉴了spring dm以后，加入了blueprint。从此以后OSGI的IOC与spring的IOC就很相似了。那么OSGI的优势是什么呢？从一开始发布OSGI，引以为傲的两大特点：模块化与热部署（动态化）。使用bundle做模块化管理，osgi做的很成熟。但是热部署并没有想象的那么好用。

OSGI热部署存在哪些问题呢？

一、（基本概念，熟悉的人可以跳过）OSGi的核心组件Bundle，与java中jar包的差别就是元数据配置：

       常用的Bundle元数据定义：

    a) Bundle-Activator：定义Activator的实现全限定类名称，此类必须实现BundleActivator接口，并实现start和stop方法。当Bundle被OSGi容器启动或停止时就会去调用start和stop方法。Bundle-Activator并非是必须的，只有在需要初始化或是销毁资源时才有用，并且不推荐在start方法中进行复杂的处理，以免加重OSGi容器启动的负担。在Spring DM中，ApplicationContext的创建和销毁就是在extender中通过实现BundleActivator接口实现的。

 

    b) Bundle-Classpath：有些jar文件是某个Bundle专属的，此时就应该把这些jar包设置到Bundle的classpath中。比如JDBC驱动等Jar包。

 

    c) Bundle-ManifestVersion：设置Bundle所遵循的OSGi规范版本，目前情况下应该将该值设置为2，表示OSGi R4版本。

 

    d) Bundle-Name：必须的，Bundle的名称，与Bundle-SymbolicName对应，Bundle-Name类似于name，而Bundle-SymbolicName类似于id。

 

    e) Bundle-SymbolicName：必须的，Bundle的唯一标识名，一般推荐采用类包的机制，保证其唯一性。

 

     f) Bundle-Version：必须的，Bundle的版本号，可用于在import-package中进行过滤。

 

    g) Export-Package：Bundle对外公开的可被其他Bundle导入的包。