我们为什么需要分布式 OSGi

随着分布式 OSGi 项目即将抵达重大里程碑，现在应当是一个恰当的时机来回顾一下我们已经完成了哪些工作、还有哪些需要做的，并谈一谈我们为什么要进行这项工作。

为迎接即将发布的 OSGi 规范 4.2 版，我们在 11 月对设计文档初稿（按 OSGi 术语叫 Requests for Comment，或简称 RFCs）做了更新。这个月，我们在 Apache CXF 发布了该版本中一个重要的新设计——即 RFC 119，分布式 OSGi——的参考实现源码。

由于当前版本的OSGi 规范已经在嵌入式领域取得成功，因此分布式OSGi（Distributed OSGi）项目被计划纳入OSGi 的下个版本，并开始为企业级应用所采纳。比如，Eclipse 插件就采用了OSGi 框架；另外，所有应用服务器厂商以及众多ESB 厂商也都接纳了OSGi。

OSGi 联盟于 2006 年 9 月召开过一个公开研讨会，深入探讨了对企业版（若可能的话）的需求（Peter Kriens 写了一篇非常好的描述此背景的文章）。当前版本的OSGi 规范已经通过 JSR 291 成为了 Java SE 的一部分，对于我们参加了该研讨会的人来说，所面临的问题是，OSGi 规范是否也应成为 Java EE 的替代方案，以及假如是的话那么需要满足哪些需求。众多关键需求中的一条是，OSGi 服务能够调用运行于其他 JVM 之上的服务，并支持企业应用拓扑，从而提高可用率、可靠性及可伸缩性。（当前的 OSGi 规范只定义了在单个 JVM 里的服务调用行为。Peter 的那篇研讨会总结文章里可以看到更多信息。）

2007 年 1 月召开了首次企业专家组会议，工作由此正式开始。分布式OSGi 始终是该议程里级别最高的需求之一。起初，我们常被批评为“重复已有工作”或“制造另一个CORBA”，不过这些都是由误解造成的。设计文档初稿（RFC 119）和参考实现代码将有助于解释清楚我们并非如此。我们只是扩展OSGi 框架来配置现有的分布式计算软件系统。我们在RFC 119 里采用“distribution software”（或简称DSW）这一术语来泛指任何能够进行远程服务调用的协议与数据格式系统。远程指的是另一个JVM 或地址空间。

有人建议我们选择一种具体的DSW（distribution software），并将其标准化。此做法的一个好处是，我们可以利用针对特定协议的功能（比如可执行代码的序列化），不过这会缩小选择范围，并可能导致产生依赖。我们并没有那样做，而是定义了一个可用于任何分布式计算软件系统的通用配置机制。我们也试图不妨碍使用像“序列化可执行代码”这样的功能——也就是说，如果你愿意的话，仍然可以那样做，只不过那不是标准化的做法，因为它是针对单一类型的DSW（distribution software）的。

除了Apache CXF 的参考实现，Eclipse ECF 项目以及Paremus 的Infinflow 产品也有意实现分布式OSGi 的设计，而且我们已经听说Eclipse Riena 项目也在作此考虑。因此，但愿我们的分布式OSGi 正走在正确的路线上。不过我们仍希望大家提供反馈，而且现在也还有时间来更改规范里的内容。分布式OSGi 的设计还包括了发现服务（discovery service）以及用于配置多分布式软件系统组件的SCA 元数据扩展。这两样东西目前尚未公开，不过应该快了。

为了说明我们目前处于什么阶段，对OSGi 联盟的运作方式做一些了解是大有裨益的。OSGi 的流程跟JCP（Java Community Process）颇为相似。实际上，OSGi 规范刚开始就是以JSR 8 出现的，而且它也基本反映了那个最初JSR 工作的进展。 OSGi 流程是从请求提案文档（Request for Proposal，简称 RFP）开始的，该文档对需求进行了详细描述。RFP 得到批准后，一个或多个满足需求的请求评论文档（Requests for Comment，RFCs）将被创建起来。当一个 RFC 得到批准后，有关规范就会进行更新，以涵盖该项设计。RFP 和 RFC 都是专家组的工作成果，尽管它们往往处于组里个别人或小部分人的带领下。

不过，OSGi 联盟在规范方面的流程是独一无二的，因为文书写作都是交由 Peter Kriens 完成的。这点好极了，因为 Peter Kriens 从一开始就跟随 OSGi 的工作，他可以确保规范的质量与一致性。而且，这也消除了其他标准化组织在把文档书写工作交给其成员（通常代表与其他成员竞争的厂商）时经常碰到的政治问题。

当前版本的参考实现是为了验证 RFC 119 的设计，并使得该份 RFC 得以通过专家组投票。在规范阶段，我们期望在把该项设计整合进规范的过程中对它做进一步讨论，这也许会引起对参考实现的进一步变动。

OSGi 专家组现在正着手于同 Peter Kriens 一起为 R4.2 版而努力，预计可于三月或四月发布初步版本，并在六月发布最终版本。关于即将发布的 R4.2 版的更多信息可以在 OSGi Dev Con 上得知。该技术大会将于 3 月 23 至 26 日在 Santa Clara 同 EclipseCon 联合召开。

R4.2 版里的另一个主要部分是对核心框架的各种扩展，比如源自 Spring 的 Blueprint Service 服务模型（用于开发 OSGi 服务）以及各种映射到 OSGi bundles 的 Java EE 部件（JTA、JDBA、JPA、JNDI、JMX、JAAS 和 Web Apps）。Java EE 映射并不如对核心的增强（如 Spring/Blueprint 或分布式 OSGi）那么成熟，它们只是一个将随 R4.2 最终版一同发布的预览。

在过去的两年里，我们已经用初稿记录了分布式 OSGi 的需求与设计，并用参考实现代码进行了演示。OSGi 规范 R4.2 企业版预计于 2009 年中发布，这是其中的一项重要特性。伴随着对 OSGi 核心框架的扩展、源于 Spring 的 Blueprint 服务组件模型以及关键 Java EE 技术的映射，即将发布 R4.2 版对 OSGi 规范和 OSGi 社区而言意味着前进中的重要一步。

阅读英文原文： Why Do We Need Distributed OSGi? 。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。