Peter Kriens 重返 OSGi 联盟

Peter Kriens 是 OSGi 背后的主要推动者，日前在其博客上宣布重返OSGi 联盟，到2012 年初为止他一直在这里担任总监长达11 年。InfoQ 联系到了Peter，与他讨论了重返OSGi 及其jpm4j 项目的最新情况。（这里所表达的观点是Peter Kriens 本人的，并不代表OSGi 联盟的观点。）

InfoQ：Peter，欢迎重返 OSGi 联盟。自从你离开之后都做了些什么，未来你又会做些什么呢？

Peter：我离开的主要原因在于我需要重返第一线。我的计算机生涯开始于上世纪七十年代晚期，非常幸运很年轻的时候就能开发高级的分布式系统。随后，Ericsson 给了我一个很好的机会来领导规模很大的项目，在完成之后，他们非常慷慨地让我于九十年代加入了应用研究实验室（Application Research lab）。毫无疑问，这些年是非常重要的成型期，直到 2001 年加入 OSGi。

但是，在编写了十多个规范之后，我感觉有时候会太多地讨论理论而不是基于深入的实践。尽管我认为这是我们这个行业所司空见惯的现象。当我无法完全掌握（in ‘my fingers’）一项技术时，会变得很不开心。这种内心的声音因为 OSGi 企业级专家组的重要性不断增加而变得更加强烈。我的经验更多的是来源于嵌入式领域，所以如此之多的“最佳”实践让我感到很困惑。

我离开的第二个原因在于仓库（repository）。我认为，当前我们处理二进制制件（artifact）的方式有很多的问题。不要误解我的意思； Maven 中央仓库对我们来说是非常重要的资产，而且不仅仅对 Maven 用户来说是这样。但是，它底层的文件 / 目录基础模型对于长期来说过于简单。应用的复杂性在不断地增长，我认为仓库需要更多的功能，它需要更加智能地组织制件。我试图在联盟中推广这样一种 OSGi 仓库，但是很遗憾的是没有得到什么响应。结合这一点，再加上我非常愿意重返第一线，暂时离开 OSGi 联盟看起来像一个不错的休假，我很享受做自己喜欢的事情！

不过，今年初我发现要做好 jpm4j 很明显需要更多的人。我开始与不同的公司接触，谈论它们是否对其感兴趣，但是我没有找到一家公司能够对其进行充分地投资。现在，业务开发并不是我的强项，并且我确实已经达到了最初的目标，因此我对此已经非常满意，很开心重返 OSGi 联盟。

InfoQ：OSGi 做了很多的工作，不过用户的采用情况似乎与之并不成比例。为了给这方面带来动力，需要做些什么呢？

Peter：我受雇就是要推动其采用情况。为了理解我们的策略，我介绍一下过去一年中我的部分经验。

对于 jpm4j 来说，我包含了 OSGi 并且基于 Bndtools 进行的开发，这是 Neil Bartlett 的一个 Eclipse 插件。我发现使用 OSGi 构建实际规模的应用是很困难的，因为大多数的 JEE 库（以及开源库）在 OSGi 中使用起来会很笨拙和别扭。因为我不想进行妥协（毕竟我是在做一个学习的练习），我开发了很多“原生”OSGi 的解决方案。我为安全、队列、配置、批处理任务、mongo、浏览器集成等问题开发了 bundle。这些组件与 JEE 或开源的对等功能相比要简单很多。我能通过几周的工作替换掉颇具规模的类库并不是因为我多么聪明，其实不是这样的。我能比较幸运地做到这一点是因为 OSGi 提供了很多的基础功能，而大多数的类库都在用专有的方式在重复这一点。通过标准化生命周期、依赖以及配置基础，这些组件内部就具有了协同的功能。如果你使用 OSGi 的话，你会发现通常只需要编写非常非常少的代码，因为环境已经处理了很多常见的、易出错的细节。在非 OSGi 的环境中，因为没有发现服务、生命周期以及配置的标准化，你会发现在不断地重复自己，还要编写很多粘合性的代码。

现在它与 Bndtools 进行了结合。我承认并没有尝试市面上的所有 IDE，但是可以肯定地说我的 OSGi 框架能够在 bundle 每天更新上百次的情况下保持运行。很美妙一点在于，你可以点击 Ctrl-S、切换到浏览器、刷新，然后就能看到结果了。这与 Ruby on Rails 的编辑 - 调试模式一样简短，但现在将 Java、Eclipse 以及 OSGi 的威力添加了进来。现在，你也有这样的蛋糕（快速编辑 - 调试周期）并可以享用（重构、快速帮助、类型安全、导航、强大的模块化以及µservice 等）了。

实际上，我对 OSGi 相当地喜爱。不过，在企业级领域可以看到它的长处，不过它也有其不足。我通常会这样说，OSGi 是相当坚实的基础，可以基于它构建最高的摩天大楼，但即便是搭建最小的房子，它所能提供的支持也少得可怜。所导致的结果就是，很多人必须要自己将这些片段集成起来。真正缺少的是一个 OSGi 应用的骨架（skeleton），它要适用于最大群体的开发人员，也就是 web 应用的开发人员。我相信，我们不用费太大的力气就能构建出这样的东西。实际上，所需的各个部分都已经就绪；所缺少的就是一种将这些部分放到完整的应用之中的一种方式。

所以，我提议为 OSGi 联盟做一个这样的骨架。IBM 的 Dan Bandera，同时也是 OSGi 联盟的主席，做了一个这样的提议并在董事会进行了讨论。我很意外地得知，他们希望我立即启动它！因为，我还想做一些关于 jpm4j 的工作，所以我会将自己的时间分给联盟和这些 jpm4j 的工作。

InfoQ：能给我们介绍一下 jpm4j 吗？

Peter：几年前，我认识到随着时间的推进，公共的仓库将会持续增长，因为你不能删除任何的修订版本。移除版本可能会破坏构建！当你使用版本范围或 OSGi 的功能 / 需求（Capability/Requirement）模型时，有一点大家可能还没有理解到，那就是增加新的版本也可能会破坏构建。使用版本范围的构建今天可能会成功，但明天可能就会失败，因为仓库中有了一个更新的版本。这就是说，在构建依赖中，仓库的内容是第一等公民。通常来讲，这是仓库中不太被大家所理解的方面，也是 Sonatype 不建议人们使用 Maven 版本范围的原因。

对我来讲，多年前我就清楚认识到仓库需要像版本控制那样的版本化，并且要与它结合起来；在 OSGi 联盟内部，基于这样的原因，我们一直使用版本控制系统来管理二进制依赖。我认为，对于基于云的仓库服务来说会是一个机会，这就像针对二进制文件的 Github。

不过，为了要对仓库进行版本化，你首先需要所有可用的制件的一个目录（catalog）。在与 Karl Pauls 和 Richard S. Hall (OSGi 提交者以及 Manning OSGi in Action 的作者之一) 经过了一周的讨论之后，得到的结论是，我需要一个公开的社区站点，它包含了所有可用制件的目录。这个目录可以作为我的版本化仓库的基础。不过，具备这样的目录也能够让我解决一个非常令人沮丧的问题，我将其称之为 Java 的最后一英里（last mile）。几乎所有的动态语言都具有在不同操作系统上安装应用程序的方式，如 NPM 、 Gem 、 CPAN 等。尽管 Java 无疑是有史以来最便利的语言，也具有便利库的巨大优势，但是开发人员要安装一个应用程序要经过很多的步骤。所以，jpm4j 具有一个 jpm 的命令，借助它就可以很简单地在本地安装应用了，它可以用在命令行之中也可以作为服务。jpm 知道在 Windows、Linux、MacOS 中应用该怎样处理并会将其安装在合适的位置之中。

这个特性尽管随着时间的推移处于了次要的地位，但它是 jpm4j 命名的原因：“Just another Package Manager for Java”。也就是说，它并没有完成还有很多的工作要做。如果这个过程全部完成的话，会有相当大的规模。如前面我所讲的，我正在与一家公司进行交流，它们愿意接收这个项目并进行进一步的开发。

InfoQ：这样听起来似乎很有意思，但是这里会不会有鸡和蛋关系的问题，启动仓库会使用大量的有用的 bundle？

Peter：当时，我的首要目标并不是 OSGi。我知道这听起来有点奇怪。Jpm4j 是一个 Maven 仓库，因为它是目前最流行的仓库模型。所以，我想将这些版本化的仓库提供到 Maven 领域之中。因为我的心思很大程度上还在 OSGi 上（比我当时所意识到的更为强烈），所以我在这里将 OSGi 作为一等公民。

开始的时候将所有的制件都放到 Maven 中央仓库是很简单直接的。jpm4j 的核心在很大程度上是 JAR 的目录，所以我为 Maven 中央仓库编写了一个扫描器并且会自动导入它们的所有制件。jpm4j 扫描所有的 JAR，并且当它探测到 OSGi bundle 的时候也会按照同样地方式列入目录之中。jpm4j 会收集 Maven 元数据和 OSGi 元数据，并且为其他的元数据提供了一个插件模型。目前在 jpm4j 中已经有 400,000 个版本信息了。

不过，尽管它是以 Maven 为中心的，但是 jpm4j 独立于任何的仓库格式。我还让它可以很容易地在 Github 上创建二进制仓库，你只需在 Github 上提供一个事后的挂钩（post hook），jpm4j 将会扫描这个库（repo）并更新它的目录。Jenkins 构建可以实现类似的挂钩。我还规划扫描所有的 Eclipse bundle，并且包含众多的企业仓库。

所以，我试图让人们能够很容易地将他们的 bundle 对整个世界开放。我以为我已经达到了这一点；实际上门槛相当低。

InfoQ：对使用者来说又会怎么样呢，他们在使用 bundle 前是不是需要迁移到 OSGi 上？或者这只是为处于新建阶段的项目准备的？

Peter：我认为不是这样的。OSGi 是一项重要的投入，因为它不像其他的一些库，对于其他的这些库来说，你只需将其加入到类路径下就能得到一些非常好的新功能。OSGi 很小，因为大多数的工作都需要你来完成，也就是用户。 Parnas 开创性的模块化论文讲的都是如何将一个问题分解为模块，这样模块之间的耦合能够最小化而内聚能够最大化。当我们传播 OO 范式时，在七十年代所学到的基本经验教训都被面向对象社区所践踏了。只有 OSGi 提供了执行这种模块的基础。

OSGi 的巨大收益是通过更少的代码做更多的事情来实现的，代码也会更容易维护。如果要做得正确的话，它会影响到开发过程的每一部分。尽管有清晰的迁移路径，但是如果没有变化意愿的话，我不会尝试 OSGi。这很类似于减肥，临时的节食很少能保证长期有效；如果你想要变得苗条并能够保持的话，你需要改变生活方式。因此，如果想要控制手边已膨胀代码所带来的成本，只有一个快速解决之道：等待直到计算机变得更快。既然摩尔定律对于传统的顺序执行程序（classic sequential program）已经过时，那么这种快速的问题解决办法会变得更加困难。

也就是说，开始使用 OSGi 是一种门槛很高的方式。太多的开发人员因为这个高门槛必须要忍受漫长的学习曲线。显然我注意到已经有应用服务器框架，但是我指的并不是这一点。这些框架并没有使用 OSGi 真正的长处。在追求 JEE 兼容性的过程中，它们很容易会将这两种环境的缺陷结合了起来。OSGi 最酷的特性在于服务模型，但是这些环境都没有包含它。我在 OSGi 方面所做的新的努力希望能够展现出如何做到这一点。

InfoQ：使用 OSGi 很大程度上需要一种开发规范（discipline），这种规范可能正是缺失的一环，它使得相对于其他的工程规范来说，软件工程是如此得模糊。不过，我们该如何期待一直按照某种方式行事的团队改变方向、在规范方面获取新的收益，并且开始按照模块的方式思考而不是专有的架构，毕竟这在我们行业是很普遍的？

Peter：完全是这样，正如我前面所说，打个比方，OSGi 是一种生活方式，并不仅仅是饮食习惯而已。

现在，你提到了有趣的一点在于我们该如何摆脱（这是什么呢，一个价值 5000 亿美元的行业？）我们的工作方式？这里有很多的原因，但是我认为根本原因在于我们并没有承担起责任。如果 Amazon 违反了服务等级协议 (SLA)，他们只需要赔偿给你就行了。如果雇员因为薪资程序的崩溃没有得到工资，那么他也只能忍着（当然，可能会延期支付或其他的方式进行支付——译者注）。如果金融工程师搞砸了财务系统，那么社会也会宽恕他们。每位超过 30 岁的企业级开发人员都曾经做过失败的项目，但是我没有听说有人因此而失去工作。相反，如果建造一座大桥，它却垮塌了，想耸耸肩膀就转身逃离是不可能的。

在嵌入式领域，软件会做得更加仔细，因为它们要为自己的软件负责。比如说，汽车公司会知道部件的任何问题都会使其陷入昂贵的法律诉讼之中。但是，在企业级软件领域几乎并没有这样的反馈循环。所造成的结果就是什么事情都可以通过。我希望我们的工程规范是唯一具有摇滚明星、趋势以及时尚的那一种。责任的缺失造成了我们行业中各种负面的激励。

我一直感到惊讶的是开发人员会花费大量的时间却会拒绝花哪怕一点点钱。在开发过程中，责任会深刻涉及到非开发人员。对于非开发人员来说，时间与金钱间的权衡会更加显而易见。我相信这会快速推进 OSGi 现状的改变。

在此之前，对于 OSGi 来说最重要的事情是推动被草根所采用的努力。这是我为 OSGi 联盟所要完成的工作目标之一。通过让 OSGi 对于大多数常见场景下更加易于使用，我们希望能够增加对 OSGi 的了解并展现服务模型所能带来的收益。很多开发人员热爱 OSGi 的架构，我认为是开始的这个部分让他们望而却步。

InfoQ：在重返 OSGi 联盟后，你还会担当其他的角色吗？

Peter：尽管这次我不会再编写规范，但是我依然会参与一些技术专家组，当然我也会再次参加一些巡回的会议。我计划推动一些规范，它们能够使 Web 应用更容易构建。我还会参加董事会的会议。对于其他 50% 的时间，我会计划进一步推进 jpm4j，因为它显然没有完成。

InfoQ：有什么事情是社区可以做的吗？

Peter：在降低 OSGi 门槛所做的努力方面，我非常乐意能得到反馈。我还希望能够与任何想讨论 jpm4j 的人交流。在这两方面，我会尽可能发挥社区的力量。

InfoQ：问一个个人问题，我曾经在各种会议上看到过您的演讲，你的演讲就像你所描述的技术那样令人屏息凝神。你是怎样做到这一点的呢，对于演讲者来说你有什么窍门吗？你总是能够找到或做出很棒的图片并将它们精炼地放在一起形成特别棒的效果，最后按照你独特的方式将其做成很有意义的文稿，你是如何做到的呢？/b>

Peter：哦，非常感谢。在这方面，每次我登台的时候，实际上都会感觉准备不充分，所以很难回答这个事先没有预料到的问题。

我唯一可以讲的就是，对于我自己来说，我是典型的以视觉为导向的。主要的原因在于我可以盯着一个 XML 文档看几个小时，却看不明白。但是，如果给我看一个好的图片，它看起来就很明显了。看一下 OSGi 规范；很少有规范具备如此精心制作的插图。主要的原因在于要确保我能真正“看懂（got it）”。我有很多朋友，它们不看图片并且能够通过 XML 文档得出相同的信息，我一直对他们有深刻的印象。我的大脑需要图像，我觉得这一点无形中影响到了我的演讲文稿。

关于作者

Peter Kriens 自 1990 年代就是独立的咨询顾问。目前，他为 OSGi 联盟和 jpm4j 工作。在八十年代，他为报社基于微型计算机开发了高级分布式应用，并且这基于当时非常新颖的面向对象技术。凭借在面向对象技术方面的经验，他曾经被很多的国际公司所雇佣，包括 Adobe、Intel、Ericsson、IBM 等等。1998 年，在 Ericsson 研究所工作期间，他参与到 OSGi 规范之中；随后他成为这些规范的主要编辑者。在 2005 年，他被授予 OSGi 院士称号。在 2012 年休假开发 jpm4j 之后，他重新回到了 OSGi 联盟来帮助推进 OSGi 的采用。他是荷兰人，不过居住在法国。你可以在 Twitter 上关注 Peter：@pkriens。

原文链接： Peter Kriens Returns to OSGi Alliance