Java技术的软肋: jar 的缺陷与OSGi的兴起

• Java技术的软肋

 

     让 我们来回 顾一下r unti me有关 的问题。 JAR文 件曾经是 Java 包管理的 中坚力量 ，但说实 话，在使 用的时候 的确有些 限制。J AR文件 只是一种 非常原始 的打包机 制，因为 没有范围 的控制。 在JAR 文件内部 就没有办 法来控制 依赖关系 ，也很难 标记版本 信息，并 且接口声 明了也无 法使用。
     当 你有一群 松散的J AR文件 时，情况 会变得更 糟。cl assp ath会 被填满。 甚至一旦 加载后， 如果你在 新的代码 里替换了 一个或多 个JAR ，JVM 不但不会 给出提示 并且它也 不会返回 到新JA R包里去 找。除非 你在cl assl oade r上实现 了一些精 心设计的 技巧，否 则你唯一 的选择是 重启JV M。在添 加新的应 用到cl assp ath时 同样的问 题会再发 生。

对Jav a这个领 域稍有了 解的话， 应该就知 道下一步 该怎么做 了。没有 悬念，我 们开始看 一下Op en Services Gateway initiative (OSGi)。

  

• OSGi

 

     O SGi联 盟是一个 开放的标 准组织， 它维护着 OSGi 的标准。 OSGi 的规范就 是一个由 Java 实现的完 整、动态 的组件模 型，所构 成的模块 化系统、 服务平台 。

    你可 以在OS Gi框架 中安装你 的应用。 应用程序 是由一系 列定义好 的Jav a class构成的OSGi bund le组建 的。应用 可以由组 件(OS Gi bund les) 的形式来 构建。该 框架支持 热部署， 因此，不 用重启J VM就能 添加或者 删除应用 。通过一 个或者多 个OSG i bund les可 以充分的 模块化应 用。对于 一些更为 松散耦合 的接口， 尤其是那 些你能预 想到有可 能被替换 的，你就 该考虑把 这样的O SGi bundle 注册成OSGi    Services，以便后期的修改。

    对于OSGi Bund les（ 相比JA R包来说 ）接口的 好处是一 旦有缺失 的依赖， 在得到可 怕的Cl assD efNo tFou ndEx cept ion错 误之前， 就会马上 提示出来 。你可以 运行多个 版本的O SGi bund le，并 最终在合 适的时候 移植。最 终，所有 Jar包 的问题现 在看起来 都不是问 题了，你 所用的是 一个强大 的，可扩 展性高并 进行过良 好优化的 应用系统 。

• OSGi 与CICS

 

     C ICS中 支持OS Gi标准 后，你就 可以把J VM Serv er所跑 的Jav a应用或 者从Ja va Pool 移植的J ava应 用打包成 OSGi  bundle。尽管一个OSGi bund le听起 来很奇怪 又复杂， 其实就是 一个JA R文件的 结合体， 再加上一 些额外的 mani fest  文件。Jar包与OSGi bund le的唯 一区别就 是在ma nife st file headers中的信息。（见图4）

     
     说OSGi bund le很有 用是因为 它在非O SGi环 境下同样 可以运行 ，因为它 的确就仅 仅是个J AR包。 从概念上 说，OS Gi bund le比一 个JAR 包更为强 大。当你 发现它的 潜力后（ 比如动态 安装和升 级，检查 依赖等） ，你会更 愿意把b undl e安装成 OSGi 架构。