BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Sebastien Auvray 关注 0 他的粉丝 ,译者 贾晓楠 关注 0 他的粉丝 发布于 2009年4月27日. 估计阅读时间: 19 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT