Ruby On... SAP：借力全新 Ruby VM，企业化路上又迈一步

SAP，占领着 CRM 和 ERP 最高的市场份额，也是第二大的商业软件公司，正准备把 Ruby 纳入 SAP NetWaver 和 SAP ERP 6.0 之中。ABAP Virtual Machine 将会通过 Blue Ruby 扩展来支持 Ruby 代码。

在 Timeless Software ，SAP 的 CTO Vishal Sikka 概括了 SAP 的发展方向。谈到软件发展，Vishal 介绍到软件产业的革新正在面临：商业变化、新的技术层次、不断改进的架构，以及最终出现新的编程语言：

编程语言和编程模型也在不断的发展。差不多每 10 年就会出现一种新的主流语言，每 3 年就会出现一种非主流语言，正好在大型应用软件的生命周期内。新的编程 模型和活跃的开发者社区也随着新语言迅速出现。例如 Ruby，和其他语言相比，其在最短时间内拥有了一百万的开发者。

Ruby on ABAP 结合了两个世界的精华，这是 Juergen Schmerder 说的：

轻量、低耦合、通过 Ruby 来实现敏捷编程，由稳健的 SAP NetWeaver Application Server ABAP 来执行。从多方面来说，Blue Ruby 让简单的事情简单化，复杂的事情可能化。

从技术的角度看，Blue Ruby 用 parse tree 来生成 BRIL 代码（ABAP VM 的字节码），用桥和虚拟文件系统来保证安全。

• 安全的桥包，通过构建一个明确的沙盒概念，来安全地访问宿主平台的底层功能。

最终你就能在 ABAP 环境中运行 Ruby 代码了（来自 Timeless Software）：

我们尽可能地重用 ABAP VM 来实现垃圾回收、会话处理、内存管理等。你要记住，跟一般的 Ruby 环境不同，它是完全运行在应用服务器上的——NetWeaver Application Server（ABAP）。这意味着这些都跑在 ABAP 工作进程、滚动区（roll area）和用户认定和授权等上面。

目前 Blue Ruby 已经覆盖了 4910 条 RubySpec 中的 3365 条（70.2%），还有一个 Webinar 。

我们会继续关注接下来的Blue阶段，其可能包括 Blue PHP 和 Blue Python。InfoQ 有幸采访到 SAP 的 Blue Ruby 的 PM，Juergen Schmerder，以及 JRuby 团队到 Charles Nutter。我们一起讨论了 VM 实现。

InfoQ：首先，像 SAP 这样的大公司是如何决定来支持 Ruby 的？Vishal Sikka CTO 考虑了编程语言？还是客户端 / 开发者反馈？的确需要轻量？还是一个人单方面的决定？

Juergen：首先，是我们决定让 SAP 支持 Ruby 的。我们尝试了这种语言，我们的团队非常欣赏 Ruby 的实用性。但我们的目标是证明 SAP 的确需要支持 Ruby——以及 / 或者其他语言。

Blue Ruby 项目是 2007 年中在 Palo Alto 的 SAP 研究中心（CTO 办公室内部的一个组织，由 Ike Nassi 管理）启动的。从那开始，我们实现了一个 Ruby 语言适当的子集（我们认为足以去收集反馈），并花了大量的精力投入到双向地无缝融合到我们那近 3 亿行 ABAP 代码中。我们所作的跟 SAP 的 CTO Vishal Sikka 所推进的 timeless software 完全同步。Vishal 甚至还在他的 blog 中拿 Blue Ruby 作为例子。这个项目最初的动机是需要一个轻量级的环境来支持我们的 SAP 应用平台。

InfoQ：你们是 BlueRuby 项目的唯一开发者吗？你们关于 Ruby 有什么经验？关于 Ruby VM 呢？这个项目是什么时候启动的？

Juergen：我们有一个小的团队全职做 Blue Ruby，有几个开发者在 Palo Alto，还有 2 个在上海的 SAP 中国实验室。公司内部还有一些其他开发者为之作了不少贡献。我们的上海同事之前在做 Xruby 项目，对 Ruby 的内部以 及语言、编译器、虚拟机等有很深的理解。我个人关于 Ruby 的经验——嗯，我从是 2007 年 9 月加入这个项目时才开始接触 Ruby 的。从那开始，我就爱上 了这个语言，把 MRI 源代码读了无数遍。就像恋爱一样，它至今还时不时给我来点惊喜 :-)

实现 Ruby 语言的 VM 有一个难点——我得投入更多的时间到编写 VM 的语言（在我们这是指 ABAP）上，比 Ruby 本身要多…… 每当我在 Blue Ruby 之外写一点 Ruby 代码，我就用 MRI 作为参照，用 JRuby 来做 Netweaver Java Stack 的实验。每当 SAP 的人问我为什么不多用用 ABAP 的 stack，我的回答是 Java 已经提供了完美的解决方案——JRuby。

InfoQ：SAP 为什么开始就决定瞄准 Ruby，而不是其他的动态语言：Python，或者其他流行的语言：Scala、Javascript、PHP……？

Juergen：嗯，我觉得你不能说我们“瞄准”了 Ruby……我们曾考虑在 SAP 中“采用”JavaScript，因为 ABAP 内核已经有了 JavaScript 解释器。因此再做一个 JavaScript 项目在 SAP 中很难通过。Ruby 在 2007 年有过很多闪光点 （TIOBE 的 2006 年度语言），它很好地结合了纯净和表达能力，我们都很喜欢这个语言。我们的长期目标，是让 ABAP VM 真正地支持多语言，因此 Ruby 其实只是我们的第一步而已。我们认为语言——不论什么原因——非常极端，并有“放之四海而皆准”的方法，就是把几百万的开发者拒之门外了。

InfoQ：你如何做技术上的选择，比如解析使用 parse tree，以及构建 AST Ruby？不使用 LLVM？不是可以利用已有的 VM，例如 JRuby 来生成 BRIL 代码吗？你不想依赖于 Java VM 吗？

Juergen：在我们刚开始写 Blue Ruby 时，我们的编译器使用 Java 实现的，用 ANTLR 来解析。后来换到了 ruby_parser，因为我们的目标是自托管的环境。Blue Ruby 应该能编译它自己的编译器，因此我们的编译器一定要用 Ruby 来写。我们考虑过在项目的未来派的一边使用 LLVM，但我们的目标平台是 ABAP， 最实用的方法就是用 Ruby 写的编译器来把 Ruby 代码编译成 BRIL 了。另外我们的主要目标是证明能够在一个调用栈中同时执行 Ruby 和 ABAP。这也是我们做一些决定的底线（例如不考虑 Java）。

InfoQ：你不认为 Ruby 的局限性，如进程方法、IO 操作和线程缺失会阻碍 Ruby 融合到 ABAP 中？

Juergen：我们并不否认你提到的缺陷使得 Blue Ruby 不如 Ruby 纯净。但我们的目标开发者是在 ABAP 空间里工作的。与 SAP 无关的开发者是不会接触 Blue Ruby 的，因为我们的实现的附加价值是让 Ruby 语言能够支持 ABAP 栈。要是这对你无关紧要，你就不需要关心 Blue Ruby……ABAP 的人很久以前就不关心 IO 操作和线程了（他们可能会想念这些功能，但没有这些一样工作）。因此这不成问题。但是，这不意味着我们以后 都不管这些了，只是现在没有什么影响。并且从我们得到的反馈来看，外面有人很欣赏在 ABAP 中运行 Ruby 的主意。

InfoQ：Charles 最近声明：

大家听着：Ruby 是很难实现的。哦，乍一看貌似很简单，而且你差不多能很快地完成 70%、80%，甚至 90%。但如果你不仔细找的话，剩下的 10% 或 5% 里面有很多可怕的东西很难注意到。

InfoQ：目前你已经支持了 70～80% 的 RubySpec。你们对剩下的 20～30% 有信心吗？有没有最后期限或者确定的目标？

Juergen：非常赞同 Charles 的观点。但是，随着时间的推移，JRuby 已经能够十分接近 100% 了，所以这并非不可能，只是有难度。在 SAP 的调研环境中，我们甚至不确定是否要达到 100%。这个项目的未来依赖于才社区得到的反馈——我们的主要问题是“在 ABAP 社 区中有没有 Ruby 的需求”。因此，下一个里程碑将由我们得到的需求来驱动。当然，也有一些不消说的事——例如我们想运行 Rails。但我猜还早。

InfoQ：下一步还有哪些特性，BlueRuby 下一版支持管道开发？

Juergen：我们在持续不断地改进内核库，并开始把标准库带到 Blue Ruby 中（至少包括那些用纯 Ruby 写的库，而不是用 C 写的）。我特别想在将来看到的是 Blue Gem。除此之外，我们很想把我们正在做的发布出去，从我们的 SDN 社区中吸引一些先期的投入者。现在已经有不少开发者表示出兴趣了。我们将会跟这些合作 者一起工作，帮助他们用 Blue Ruby 写一些实用的（但愿如此）东西，并让他们驱动我们的优先级。例如，如果 ABAP 程序的 Ruby 单元测试框架的需求比 SMTP 更强烈，我们就去做单 元测试框架……我们还想找出一些方法让其他人给我们的项目写一些代码——当然，SAP 并没有开源的传统，因此我们得先打开一些们。

InfoQ：Charles，你最近在 twitter 中谈到 BlueRuby，用了这样的说法：

好吧，事情开始变得有点荒唐……又一个 Ruby 实现，这次是 SAP 的 ABAP VM

InfoQ： 你能澄清一下吗？

Charles：我的意思肯定不是说 BlueRuby 荒唐。实际上，由于我对 ABAP 知之甚少，这听起来是个很好的主意。我发牢骚是因为在所有运行 Ruby 的 VM 中，现在至少都有一个实现（有的更多）。我很乐意看到 Ruby 有这么多的归属，但有这么多不同的实现还是有点荒唐。我认为这对 Ruby 是件好事。

InfoQ：你今天在实现一个 Ruby VM 时，有什么特别大的错误是你不想再犯的？

Charles：嗯，在实现 Ruby 的兼容性之前我不会再试图去优化了。原因主要有两个：第一，如果先优化再做兼容性，你的优化很可能破坏了兼容性。第二，当你已经让一些东西运行得足够快时，就很可能不愿意去修复一些边界情况以免变慢。最后，任何 Ruby 实现如果想要有兼容性，就得首先保证兼容，然再优化性能，因为这比看上去要难得多。

InfoQ：根据你在 Java VM 上的经验，Java VM 和 Java 语言是不是实现一个新 Ruby VM 的选择？

Charles：我认为 JVM 是目前最好最快的途径，不论对于静态语言还是动态语言。当然它也不是完美的；我们不得不做了一些 工作让 JRuby 的性能也一样好。而定制的实现，例如 MacRuby 可能会在短期内达到与 Ruby 一样的性能。但我们从 JVM 中得到的更多；JRuby 内 核类实现是目前最快的，甚至比纯 C 的实现还快，这主要是归功于 JVM 所作的优化。

至于语言嘛……Java 的确不算是一种糟糕的语言。它是 JVM 上的“C 语言”，基本上就是直接映射到其他语言的 JVM 语义上。JVM 上有很多其他语言更适 合来写应用程序，比如 Scala、Ruby、 Groovy，以及 Python，但在那些空的且快得要命的库以及框架代码上，Java 仍然是王牌。这一点在短期内不会改变。

InfoQ：你能告诉我们使用 JRuby 而不是 parse tree 或者其他解决方案来解析 Ruby 代码的优势吗？还有，你是如何让说服 Juergen 去使用 JRuby 或 JRubyParser 的？

Charles：这一点我必须承认有些疏忽……因为我不是非常清楚 ABAP 的工作方式。新的 JRubyParser 项目起初是 作为副产品产生的，因此外部的 JRuby 的 parser 用户——主要是 IDE 项目，例如 NetBeans、RadRails 和 3rdRail——可以联合 快速开发代码独立的 JRuby 项目。我们本想让那些用户自由地构建更好的 JVM 用的 Ruby 解析库，同时也让我们自由地修改解析器和 AST 来支持更高的性 能和更小的 JRuby 内存占用。

我假设 JRubyParse 只对 Juergen 和 BlueRuby 是有用的，如果他们能在 ABAP 代码之外运行 Java。但是坦率地说，我认为他们的使用 ruby_parser 的方法也非常棒；我知道 Ryan Davis（ruby_parser 的作者）投入了大量的时间和精力在这个库上，我希望在我的一些项目中用它，因为它具有友好的 API 和标准化的输出。它 也许不会跟 C 或 Java 写的解析器一样快，但这并不是 BlueRuby 所担心的。

InfoQ：JRuby 是一个很成熟的项目，你知不知道它从开始投入了多少人力？下一步的计划？重要的里程碑？你仍然像开始那样有目标明确吗？

Charles：JRuby 是很成熟。我们一年前就有了商业产品，没有其他的实现能达到这个里程碑。JRuby 应用于政府、电 信、工具，以及很多领域。关于人力……很难讲。所有的 JRuby 贡献者都投入了很长时间，每天超过 8 小时，而且我们正在飞快的进步。另外我们仍在关注 JRuby 为 Ruby 开发者开放新的机会，比如这周宣布的 JRuby 用于 Google AppEngine。JVM 绝对是语言和应用开发的不二选择，我觉得我们才看到了个开始。

InfoQ：Charles，你有没有问题想问 Juerge，关于他的 VM 实现能更好的阅读。

Charles：你认为 Ruby 的特性中哪些实现起来最难？

Juergen：嗯，这个问题不太好回答。有些特性我们目前不打算支持（比如网络接口、线程、C 库等），因为 ABAP VM 中没有相似的功能。我们得做很多迭代，直到方法调度一个异常能正确处理，现在我们已经很接近了。类型系统的工作很多，同时也是最无趣的部分。发布将促 使我们更快进步——其实没有那么难，只不过我们喜欢研究，实现 String#fct2500 对我们没有什么吸引力。

Charles：BlueRuby 有没有开源计划？社区开发者能出一份力吗？

Juergen：就我而言，我希望 SAP 有一天能允许我们在开源许可证下发布 Blue Ruby，我正在为此而努力。然而，SAP 发布开源软件的历史可不算长（在这个领域我们才更开始，就像我们在 Ruby 社区刚开始一样），而且我们的律师必 须得找到一个把传统 ABAP 应用程序许可证与开源部分相结合的方法——因为 Blue Ruby 只有在 ABAP 应用中才有意义。因此我现在不能给出任何承诺。不过，我们刚刚启动一个尝试性计划，并让很多 SAP 伙伴愿意参与。这个尝试性计划的 结果最终一定会驱动我们的优先级，我们的合作伙伴也会更加积极地参与其中。由于这是基于专门的许可协议，因此不能应用于大社区，但这只是个开始……

Charles：你认为 ABAP 在运行 Ruby 方面最重要的是什么？有什么缺点？

Juergen：ABAP 环境有非常多的优点。它本身是一个企业级应用服务，因此我们无需担心它的扩展性、部署、用户访问控制等等。整个应 用服务的最大优势在于现有的应用程序——SAP 覆盖了所有工业的和几乎所有国家的业务流程的每个领域（可能是财会、HCM、CRM、SRM、SCM，以及 我忘记列出的所有领域）。使用 Blue Ruby，我们能本地访问已经写好的近 3 亿行 ABAP 代码。而且我们可以用一种现代的高效的语言来使用、移植和扩展这些系统内部的应用程序。

从我们每天经历的消极面来看，ABAP 只是用来写商用软件的语言，而不是实现其他 VM 的宿主语言。与 Java 不同，它仍用于这个目的，还没有进化到 “ABAP-VM 的 C”（回应 Charles 关于 Java 的声明）。因此我们有时候不得不使用低效率（也就是慢）的实现来达到兼容的目的，因为 ABAP 不 提供其他方式。ABAP 是用字节码解释的，与 JIT 不兼容，因此我们实际上是在一个解释器中运行这另一个解释器。在我们在不断重构我们的代码来解决兼容性 问题，并尝试效率更高的方式的时候，我们也发现 ABAP 工具缺乏对重构的支持。我们后来开始重写大部分代码，因为做调整用的时间更多。

然而，要说这是“ABAP 的缺点”也不太公平，因为我们并没有按照它设计的目的来使用它。实际上我们是在滥用这个语言，因此我们不应该抱怨它的任何短处。记住，我们是在搞研究：）

查看英文原文： Ruby On… SAP: One More Step In The Enterprise With A New Ruby VM