采用 OSGi 框架开发项目的十个问题

近期，InfoQ 针对 Java 模块化（基于 OSGi）这一热点技术问题连续做了四篇深度报道：

• 模块化 Java 简介
• 模块化 Java：静态模块化
• 模块化 Java：动态模块化
• 模块化 Java：声明式模块化

其中对 OSGi 的基本概念和现状以及模块化技术细节做了详细描述：

OSGi 是 Java 领域里无可辩驳的最成熟的模块系统，它与 Java 几乎是如影相随，最早出现于 JSR 8 ，但是最新规范是 JSR 291 。 OSGi 在 JAR 的 MANIFEST.MF 文件中定义了额外的元数据，用来指明每个包所要求的依赖。这就让模块能够（在运行时）检查其依赖是否满足要求， 另外，可以让每个模块有自己的私有 classpath（因为每个模块都有一个 ClassLoader）。这可以让 dependency hell 尽早被发现，但是不能完全避免。和 JDBC 一样，OSGi 也是规范（目前是 4.2 版），有多个开源（及商业）实现。因为模块不需要依赖任何 OSGi 的特定代码，许多开源类库现在都将其元信息嵌入到 manifest 中，以便 OSGi 运行时使用。有些程序包没有这么做，也可以用 bnd 这样的工具，它可以处理一个已有的 JAR 文件并为其产生合适的默认元信息。自 2004 年 Eclipse 3.0 从专有 plugin 系统切换到 OSGi 之后，许多其他专有内核系统（JBoss、WebSphere、Weblogic）也都随之将其运行时转向基于 OSGi 内核。
…

不过，Java 社区领袖 Adam Bien 最近在其博客中认为，从技术角度讲，OSGi 的确是实现模块化的可行办法，但 OSGi 的主要挑战不是技术，而是模块和 bundle 的管理。他建议在决定采用 OSGi 框架开发项目之前，考虑以下问题：

1. 针对模块（bundle），采取何种版本控制方案？大、小版本如何定义？
2. 采用何种软件配置管理策略？允许开放和维护模块所有版本的分支吗？预计要维护多少个分支？通过 SVN 吗？
3. 在生产环境中，同时存在多少不同版本的模块？
4. 针对模块和模块组合，如何进行测试？每一个版本都会显著增加复杂度。
5. 采用何种发布管理策略？提供客户专属的模块组合吗？缺陷修补 / 补丁策略是什么？
6. 需要在系统运行中替换模块吗？如何处理正在进行的事务？
7. 对于 Eclipse RCP 应用，是否应该开放插件给最终用户？
8. 采用何种软件分发系统？很多公司已经有了一套软件分发系统。应用和 JVM 经常打包到一个二进制文件中整体安装。增量更新几乎是不可能的。
9. 模块之间如何交互？只通过 Java 接口吗？如果是，那么 JPA 实体的直接关联如何处理？
10. 是否采用 Maven 描述模块和 OSGi？Maven 模块版本会在 OSGi bundle 版本中得到体现吗？

Adam Bien 认为，在深入思考这十个问题之后，OSGi 可能就不再是项目的最佳选择。

读者朋友是否同意 Adam Bien 的观点，针对他的十个问题，有何看法？在实际开发中又是如何解决的？欢迎踊跃发表意见。

即将召开的 QCon 北京2010 大会设有“设计优良的架构”专题，关心 OSGi 架构应用的读者可能会对其中的“设计可扩展的架构”、“架构与最佳实践及创新的关系”等演讲感兴趣，敬请关注。