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

  • Sebastien Auvray
  • 贾晓楠

2009 年 4 月 26 日

话题:JavaRuby语言 & 开发架构

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

JavaRuby语言 & 开发架构