Eric Newcomer谈OSGi的未来

　　Eric Newcomer现任IONA科技公司CTO。Eric有26年的计算机从业经验，其中15年是在DEC/Compaq公司度过的。他是 《Understanding SOAwith 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的SOARuntime 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。