我们为什么需要分布式OSGi

作者 Eric Newcomer 译者 徐涵 发布于 2009年4月27日 上午12时5分

社区

Java,

SOA

主题

规范

标签

OSGi,

Spring框架

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

1. 返回顶部

   OSGI 我看好你哦

   2009年4月27日 上午3时41分 发表人 刘 恒涛

   希望OSGI 能够在更早的应用于一般的企业信息系统中来。

   回复

2. 返回顶部

   Re: OSGI 我看好你哦

   2009年4月27日 下午8时49分 发表人 huisheng xu

   希望OSGI 能够在更早的应用于一般的企业信息系统中来。

   太难了，对原有系统改造太大。除非找到更便捷的集成方式，否则负担不起系统平台迁移的痛苦。

   回复

3. 返回顶部

   有了分布式OSGi，EJB还有用武之地么？

   2009年4月28日 上午12时42分 发表人 cao yunfei

   现在EJB的卖点就是分布式对象，有了分布式OSGi，就可以提供分布式boundle级别组件调用，粒度比对象大，但是也够用。分布式OSGi还有OSGi的种种优势，相比之下EJB就逊色了，EJB前途暗淡呀。

   回复

4. 返回顶部

   期待

   2009年5月11日 上午3时34分 发表人 Nile Black

   osgi还是分布式的，期待！

   回复

5. 返回顶部

   Re: 期待

   2009年5月20日 下午10时10分 发表人 honnom chen

   开源项目中已经有很多采用了OSGI,比如作为开源esb的ServiceMix4.0版本正式基于OSGI的，Camel2.0也是基于OSGI.

   回复

• 更早的 >