我们为什么需要分布式 OSGi

阅读数:7389 2009 年 4 月 27 日 00:05

随着分布式 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 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评论

发布