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