Eric Newcomer 谈 OSGi 的未来

Eric Newcomer 现任 IONA 科技公司 CTO。Eric 有 26 年的计算机从业经验，其中 15 年是在 DEC/Compaq 公司度过的。他是《Understanding SOA with Web Services》一书的作者，并参与了很多有关 Web Service 的重要规范和标准（如 WS-CAF、WS-TX）的制订。他目前还担任 OSGi 企业专家工作组的联合主席。

Mark Little (ML)：Eric，你好。你可以就你自己以及与 OSGi 的关系做点介绍吗？

Eric Newcomer (EN)：好几年前，我们为实现移动设备上的应用分发，就开始考察 OSGi，但最后未能有任何具体成果。

去年夏天，我收到 IONA 于 2006 年 9 月 11 日参加 OSGi 企业工作组的邀请。但那天正好是我休假后的第一个星期一，因此就找了其他人看是否能代替我去。最后没有找到，所以也就没参加这个小组。不过，我推荐了 IONA 参加 OSGi 的企业专家组（Enterprise Expert Group，EEG），我志愿担任这个小组的联合主席。

我认为，OSGi 只有有了企业的参与后，才能对整个行业产生影响，我相信 IONA 能成为其中的一股重要力量。

ML：OSGi 存在的时间不短了，但似乎是最近才引起人们比较多的注意。你如何看待这个问题呢？

EN：真正让 OSGi 引起大众关注的是 Eclipse。而且我认为，绝大多数人也是通过 Eclipse 来认识 OSGi 的——Eclipse 平台是 OSGi 的一种实现，你下载安装的每个 Eclipse 插件，实际上在内部都使用了 OSGi。

但我要强调的是，这样认识 OSGi 是不够的——OSGi 还包括了符合当前面向服务趋势的编程模型，同时也支持动态发布（在企业级 IT 环境中，这一点越来越受到人们的重视）。

ML：IONA 在 OSGi 中最为关注的是什么？

EN：和其他很多公司一样，我们对 OSGi 最为关注的是其将大型软件项目有效分解并实现动态发布的能力。

同时我们也很重视 OSGi 在满足企业当前 IT 需求方面的潜能。我们认为，它所包含的分发平台、编程模型和运行时环境，使它在构建 SOA 应用方面具有重大优势，可以像 Eclipse 平台为软件工具所做的那样，为企业的 IT 系统创造一个良性的生态环境。

业界也已为轻量级工具替代 JEE 做好了准备，比如对于 Spring 与 OSGi 的结合，我们对此具有浓厚的兴趣。

SOA 的基础结构需求与过去的 JEE 应用服务器、EAI 代理等有明显差异——SOA 需要轻量化的、最好是在现有基础上经过改进和优化，而不是全新的东西。OSGi 在这个领域具有很大的优势。

ML：ESB 已经独立发展多年，现在突然间所有流行实现都要向 OSGi 靠拢。你认为 OSGi 真的可以和 ESB 协同工作吗？

EN：当然。首先，在 OSGi 提供的开发和发布平台上，ESB 如鱼得水，可以充分使用 OSGi 的服务和工具。这将大大缩短 ESB 新特性和新功能的研发周期，快速推向市场，并使 ESB 发布更易于管理。第二，OSGi 编程模型为创建标准接口，让 Java 容器调用 ESB 功能提供了可能。最后，我相信大家都看到了 OSGi 以最优方式切入 ESB 市场的可能性——OSGi 成为 ESB 的运行平台，厂商都可以开发运行于它之上的 OSGi 插件。事实上，我认为 OSGi 是一个普适于 SOA 架构的平台，这一点已经在 JBI V2 和 Eclipse 的 SOA Runtime Framework 项目中体现出来。

ML：OSGi 委员会内部的工作进展如何？

EN：在 6 月 28 日的慕尼黑会议上，我们完成了需求讨论，进入了设计阶段。也就是说从现在起，好戏真正开场了。

任何在多个组织工作过的人都知道，每个组织都有自己的办事流程和方法。在 OSGi 中，最初应该提交正式的 RFP（Request for Proposal）需求，需求委员会审核通过 RFP 后，专家组成员开始编写 RFC（Request for Comment）——即阐述需求解决方案的设计文档。此后（也可能同时），专家组成员会编码完成参考实现（Reference Implementation，RI），再由某人（可能和 RI 编码者不是同一个）完成一致性测试（Conformance Test，CT）。只有完成 RI 和 CT 后，规范才算完整。因此，我们目前刚刚开了个头，但我们无疑是开了个好头。

去年 9 月，企业工作组会议（会议声明、会议纪要）完成了初期需求的收集和整理。12 月，OSGi 决定成立EEG，并于今年1 月底在爱尔兰的都柏林召开了第一次EEG 会议。这次会议订立了工作流程，此后到现在共整理出大约13 个RFP。两周前，EEG 对其中的7 个RFP 投票审核通过，也就是说现在已进入设计阶段。

在提交的RFP 基础上，我们将花费大量时间，研究如何将现有的企业级技术（如Spring、SCA、JEE、JBI、Web Service 等等）引入OSGi。

ML：未来几年中，OSGi 可能在哪些方面发生重大变化？

EN：重大的基础性变化应该不会有。我认为扩展现有能力，以期满足企业需要是我们工作的重点。熟悉 OSGi 的人都知道它源于嵌入式应用，早期面向家用自动化，然后是汽车自动化和移动电话应用系统的管理。因此一个问题也就随之而来——一个企业版的 OSGi，是否能和嵌入版的一样呢？是否需要增加其他东西？我们会很自然的想到 J2ME、J2SE 和 J2EE（现在应该是 JME、JSE 和 JEE 了，因为已经都是 Java2 平台）的划分策略。但到目前为止，这个问题对于 OSGi 的答案是，我们绝对不会这样做。OSGi 自身会做一些扩展和提升，以满足企业环境中的 IT 需要，但其内核，不会发生变化。

很多扩展支持都以 RFP 形式提交讨论了，我们不久就会看到，如优化的 JEE 组件映射机制（比如 JNDI、JDBC、RMI 以及对象序列化）、对 Web 应用更好的支持、对同一 JVM 中用户代码和厂商代码发布的更高安全性支持、OSGi 内部如何访问外部操作系统（反之亦然），以及部署于远程 OSGi 环境的服务的发现方式等等。

ML：有人认为 Sun 应该在 EE7 中选择 OSGi 作为容器，你觉得呢？

EN：绝对是，这样一来可以解决很多问题。Sun 选择接受 OSGi 还是继续与之对立，是关乎 Java 未来的一件大事。就我个人对 OSGi 的认识而言，我认为，Sun 如果接纳了 OSGi，Java 将在很多方面取得重大进步，比如模块性、版本控制和类加载等等。

在 JSR 291（目的是将 OSGi 引入到 Java 标准，成为 JSE 的官方组成部分）表决会上，Sun 投了反对票。虽然最终是通过了，但 Sun 此举表明了它的意图。Sun 自己发起的 Java 模块系统规范 JSR 277，其实和 OSGi 的重迭部分很多。在此当口，Sun 面临着在 Java7 中引入 OSGi 的重大机会，但尽管尚未看到官方表态，很多迹象都表明 Sun 要走中间路线，而不是正面欢迎 OSGi。

我希望 Sun 在 OSGi 的问题上，能尽快回归理性。其实反过来看，如果 Sun 真的继续与 OSGi 对立，OSGi 的未来或许更为光明，因为业界形势已经是今非昔比了。

查看英文原文： Eric Newcomer on the future of OSGi - - - - - -

译者简介：罗小平，上海某大型公司互联网中心技术总监， CSDN 大版主，网络 ID 为 lxpbuaa(桂枝香在故国晚秋)，曾著有《Delphi 精要》一书。个人博客为 http://blog.csdn.net/lxpbuaa ，现在 CSDN 主持翻译国外专家 Herb Sutter 的中文博客。他的 Email 和 MSN 为 lxpbuaa AT 263.net 。