CRMおよびERPの市場占有率で首位を誇り、ビジネスソフトウェア会社の規模としては第2位のSAPが、同社のSAP NetWeaverならびにSAP ERP 6.0ソリューションの一部としてRubyを採用しようとしている。ABAP Virtual MachineはBlue Ruby(リンク)拡張を介してRubyコードを実行できるようになるだろう。
SAPの最高技術責任者Vishal Sikka氏はTimeless Software(リンク)の中で、SAPの方針を概説している。ソフトウェアの進化について語るSikka氏は、ソフトウェア産業が直面している変化として、ビジ ネスの変化、新しい技術レイヤ、進化するインフラ、いよいよ出現してきたプログラミング言語を次のように紹介している：
変化を取り巻くプログラミング言語やプログラミングモデルでさえ、絶え間なく進化しています。およそ10年ごとにメジャーな新言語が出現し、そして大規模 アプリケーションのライフサイクルの中では、3年ほどごとにマイナーな言語が出現します。新言語の周辺には、新しいプログラミングモデルと組織のしっかり した開発者コミュニティがまたたく間に発生します。たとえばRubyでは、過去のいかなる言語をもしのぐ速度で、プログラマーの人数が百万人に達したと言 われています。
Juergen Schmerder氏(リンク)が述べるところによると、ABAP上のRubyは双方のベストを結合したものである：
Rubyを介することにより軽量で疎結合、アジャイルなプログラミングになり、そのプログラミングが、堅牢かつ実績のあるSAP NetWeaver Application Server ABAP内で実行されます。Blue Rubyはいろいろな意味で、単純なことを単純にし、複雑なことを可能にします。
技術面では、Blue Rubyはパースツリー(リンク)を使ってBRILコード（ABAP VMバイトコード）を生成する。Blue Rubyはブリッジと仮想ファイルシステムを利用して、セキュリティ対策を行っている：
- セキュアなブリッジパッケージにより、サンドボックス概念の明確な定義の確立を通じて、基礎をなすホストプラットフォームの機能性へのセキュアなアクセスが可能になります。
最終的には、ABAPのコンテキストの中から（Timeless Softwareから）Rubyのコードを実行できます：
ガベージコレクションやセッション処理、メモリ管理といった用途に、ABAP VMを可能な限り再利用します。 標準的なRuby 環境とは異なり、これがすべてアプリケーションサーバー、つまり、NetWeaver アプリケーションサーバ（ABAP）という環境で動作していることを忘れないでください。ABAPの作業過程やロール領域、ユーザー認証＆認可などの標準的なコンテキストにおいて、このすべてが動作していることを意味します。
現在のところ、Blue Rubyは4,910の全RubySpec(リンク)仕様のうち、3,365（70.2%）をカバーしている。 オンラインセミナーも用意されている(リンク)。 Blue PHPやBlue Pythonが入ることになるかもしれない、Blueの次段階についても追跡を続ける予定である。
InfoQでは、SAPのBlue RubyプロダクトマネージャーのJuergen Schmerder氏、JRubyチームのCharles Nutter氏と情報交換する機会を得た。VM実装に関して対話するこの上ない機会であった。
InfoQ：まずお尋ねしたいのですが、SAPのような大企業がRubyをサポートするとどのように決定したのですか。Vishal Sikka最高技術責任者による、プログラミング言語に関する考えでしょうか。クライアントや開発者からのフィードバックでしょうか。現実的に軽量なもの が必要だったのでしょうか。元々は単独のサイドプロジェクトだったのでしょうか。
Schmerder氏：最初に申し上げますが、SAPがRubyをサポートすると決定したわけではありません。現在Rubyの実験中で、私たちのグループ はRubyの有用性についてとても肯定的に考えています。しかし、SAPがRubyを実際にサポートすべきか、Rubyや他の言語をサポートすべきか否か を証明することが、私たちの使命なのです。
Blue RubyプロジェクトはパロアルトにあるSAPリサーチセンターで（最高技術責任者オフィス内にある、Ike Nassiが管理するグループにより）2007年なかばに開始されました。それ以来、（フィードバックを求めるには十分と私たちが考えるほどの）Ruby のかなりのサブセットを実装し、3億行近くある既存のABAPコードとのシームレスな双方向統合を目指して多大な努力をしてきました。私たちが行っている ことは、SAPの最高技術責任者Vishal Sikkaがtimeless softwareを中心としたSikkaのビジョンの中で奨励していることと完全に一致するものであり、Sikkaは自身のブログ(リンク)の中で例としてBlue Rubyに言及さえしています。プロジェクトの元々の動機として大きく作用したのは、我が社のSAPアプリケーションプラットフォームの消費および改作 に、軽量の環境が必要なことでした。
InfoQ：BlueRubyプロジェクトの開発者はSchmerderさん1人だけですか。Rubyではどんな経験をお持ちですか。Ruby VMの実装ではどうでしょうか。プロジェクトの開始はいつでしたか。
Schmerder氏：パロアルトでは2、3人の開発者を抱えた小規模チームがフルタイムでBlue Rubyに携わっており、上海のSAP China Labにさらに2人開発者がいて、社内の他の開発者からも貴重な貢献をしてもらっています。上海の2人は以前Xrubyプロジェクトに携わっていたので、 Rubyの内部や言語、コンパイラ、仮想マシンなど、全体的に非常に深くまで理解しています。私自身のRubyの経験はというと、2007年9月にプロ ジェクトに合流したとき、Rubyに夢中になりました。それ以来、Rubyにほれ込んでおり、MRIソースコードを何度も精査しました。どんな関係におい ても時々サプライズがあるように、私もいまだRubyにはたまに驚かされます。:-)
Ruby言語向けのVM（私たちの場合はABAP）実装で好ましくないのは、Ruby自体よりも、VMのホスト言語を対象にした作業が多いということで す…。Blue Rubyの外でRubyのコードを書かなければならない場合はいつも、MRIをリファレンスとして使い、Netweaver Java Stack上で行うあらゆる実験にはJRubyを使っています。そして、SAPの社員に「なぜ取り組みの対象をABAP Stackに制限しているのか」と尋ねられればいつも、Javaにはすでに「JRuby」という完ぺきなソリューションが存在するから、と答えていま す…。
InfoQ：Pythonなどの他の動的な言語や、Scala、Javascript、PHPといった人気のある言語ではなく、SAPがまず Rubyをターゲットにすると決めた理由は何ですか。
Schmerder氏：そうですね、Rubyを「ターゲットにした」と言えるかどうか、確かではありません…。ABAPのカーネルにはすでにJavaScriptが間違いなく統合されていますから、SAPではJavaScriptは「お手つき」状態と考えました。ですから、また別のJavaScriptプ ロジェクトをSAPで正当化しようとしても、難しかったでしょう。2007年、Rubyにはとても勢いがあり（2006年のTIOBE言語オブ・ザ・イ ヤー）、Rubyには純粋さと表現の豊かさが丁度いい具合にミックスされていて、つまり、私たちは単にRubyが気に入ったのです。しかし、私たちの長期 ビジョンは、ABAP VMの真の多言語化ですから、Rubyは実際には単なる第一歩です。言語は、理由は何にせよ、二極化することが多く、「１つで何でもカバーします」という ようなアプローチを使うと、何百万人という開発者を決まって締め出してしまうのです。
InfoQ：AST Rubyのパースや構築にパースツリーを使うといった技術的な選択をどのように行ったのでしょうか。LLVMは使わないのでしょうか。JRubyのような 既存VMのひとつをハッキングしてBRILコードを生成できませんか。Java VMには依存したくなかったのですか。
Schmerder氏：最初にBlue Rubyを始めたとき、パース用のANTLRを使ってJavaにコンパイラを実装しました。自己ホスティング環境を目指しているため、その後 ruby_parserに切り替えました。Blue Rubyは独自のコンパイラをコンパイル可能にならなければならないので、コンパイラはRubyで記述する必要があります。このプロジェクトのもっと先で は脇道としてLLVMを検討しますが、目標プラットフォームがABAPなので、Rubyで書かれたコンパイラを使ってRubyをBRILにコンパイルする ことは、最も実践的なソリューションでした。そして証明したい主な点は、1つの呼び出しスタック上でRubyとABAPコードを並行で実行可能ということ でした。これがあったので、私たちの決定事項の中には、周辺条件（たとえば、Javaを考慮しない、など）が決められてしまったものもありました。
InfoQ： Rubyプロセスのメソッド、IOオペレーション、スレッドの欠如に関する制限により、ABAPにおけるRubyの導入が遅れる可能性があるとは思いませんか。
Schmerder氏：挙げられた制限が原因で、Blue Rubyを思いとどまるRuby純正主義者が存在する可能性も否めません。けれども私たちがターゲットにしている開発者は、いずれにせよABAPの領域で 作業します。Ruby 言語をABAPのスタックで利用可能にすることこそが、私たちが行う実装の付加価値となるわけですから、SAPと全然関係のない開発者がBlue Rubyに触れることは決してないでしょう。ABAPのスタックがどうでもよいなら、Blue Rubyもどうでもいいでしょう…。しかし、ABAPを扱う人々は数十年の間、IOオペレーションやスレッドを切望したことはないので（そうした機能があ ればいいなと思ったことはあるかもしれませんが、なくてもうまくやってこれたのです）、欠落しているからといって、Blue Rubyを導入しないとは思いません。今後長期間にわたって、この欠落を埋める努力をしないと言っているわけではなく、現時点の懸念事項ではないと言って いるだけです。これまでに受け取ったフィードバックによると、ABAP内でRubyを走らせるという考えを大変気に入っている人々が存在すると言えるで しょう。
InfoQ：Nutter氏が先日、次のように述べていました(リンク)：
皆さん、聞いてください。Rubyの実装は難しいのです。そう、ちょっと見たところでは簡単に思えるかもしれません。恐らくは実装の70%〜80%、ある いは90%さえ短時間で達成できるかもしれません。けれども、最後の10%か5%にはとてつもないものが残っており、予想していなかった場合は、まったく の不意打ちをくらうのです。
Schmerder氏：Nutterさんとはまったくの同意見です。それでも、JRubyは時間の経過とともに100%という数字にかなり迫るまでになっ ているので、不可能ではなく、ただ難しいのです。SAPの研究環境では、100%を手に入れようと試みるかどうかも定かではありません。プロジェクトの将 来は、コミュニティから今後受け取るフィードバックにかかっているのです -- 私たちの一番の質問はこうです -- 「ABAPコミュニティにRubyの需要はあるのか」。ですから、次のマイルストーンは、要件が原動力となるでしょう。もちろん、Railsを実行したい などといった、分かりきったこともあります。しかし、それはまだ少し先の話です。
InfoQ：BlueRubyの次期リリース向けの次の機能、現在開発中のものは何ですか。
Schmerder氏：私たちは常にコアlibの範囲を改善しており、Blue Rubyに標準libを導入し始めています（実装されるライブラリはCではなく、最低でも純粋なRubyです）。近い将来、確実にもたらしたいと思ってい るのがBlue Gemです。それ以外では、たいてい公開してSDNコミュニティから早期採用者を募っており、開発者2人が興味を持ちました。この2人のパートナーと協力 して取り組み、Blue Rubyで（願わくば）何か有用なものを構築できるよう支援する予定で、2人に私たちの優先事項を押し進めてもらうつもりです。たとえば、ABAPプログ ラム向けのRuby単体テストフレームワークに対する需要がSMTP libの需要を上回るなら、単体テストフレームワークを構築するでしょう…。また、他の人たちが私たちのプロジェクトにコードを貢献できるようにする方法 も模索しています -- しかしながら、SAPにはオープンソースの伝統がないため、まず閉まっている扉の鍵を開けなければなりません。
InfoQ：Nutterさん、あなたは最近BlueRubyについて次のようにTwitterでつぶやいていますね：
オーケー、ちょっとばかばかしいことになってきています…また新たなRubyの実装です。今回はSAPのABAP VM向けです
InfoQ：どういう意味か、説明していただけますか。
Nutter氏：BlueRubyが ばかばかしい、と言うつもりはさらさらありませんでした。実際、ABAPに関する私のわずかな知識から考えても、Blue Rubyは素晴らしいアイデアのように思えます。私があのようにつぶやいた理由は、Rubyを実行できるあらゆるVMに対して、現在のところ少なくとも1 つ（時にはそれ以上）の実装が存在するようだからです。Rubyがあちこちにたくさんあるのはうれしいですが、存在する実装がほとんどばかばかしいと思え るほど、あまりにも多岐にわたっているということです。Rubyにとってはよいこと、と思います。
InfoQ：今日Ruby VMを実装するとしたら、過去のエラーの中で、今度は絶対に繰り返さないと思っている最大のエラーは何ですか。
Nutter氏：そうですね、Rubyの互換性を達成する前に、Rubyの最適化を試みることは絶対にないでしょうね。これには2つの大きな理由がありま す。まず、最適化してから互換性に取り組むと、互換性を壊すような方法で最適化してしまう可能性が非常に高くなります。そして第二に、非常に高速で動作す るものを手中に収めてしまうと、速度を低下させる境界ぎりぎりのケースは直さないでおこうと、そちらの方向にとても心が動いてしまうからです。真の互換性 が望まれるあらゆるRuby実装においては、詰まるところ、「最初に」互換性を達成し、その後にパフォーマンスに取り組まなければなりません。なぜなら、 見かけよりずっと難しいからです。
InfoQ：Java VMにおけるNutterさんの経験に踏まえると、Java VMは新しいRuby VMを実装する上で選択すべきVMですか。そういった場合、Javaは選択すべき言語でしょうか。
Nutter氏：新しい言語が静的であろうが、動的であろうが、その種類にかかわらず、JVMは、新しい言語をすばやく立ち上げて前進させる最良の方法と 思っています。確かに完ぺきではありません。JRubyのパフォーマンスとJRubyでできることを達成するためには妙技を多数駆使しなければなりません でしたし、恐らくMacRubyの ようなカスタムの実装の方が、より優れた直線的なRubyパフォーマンスを短期的にはもたらすでしょう。しかし、JVMからは、そのコストを越えてはるか に大きなメリットが得られるのです。JRubyのコアクラス実装は見渡す限り最速で、その速度は手を加えていないC実装をしのぐほどで、それを可能にして いるのは主に、JVMが代行してくれるあらゆる追加的な最適化なのです。
言語について言えば、Javaは実際、それほど悪い言語ではありません。JVMの「Ｃ」であり、今でも、JVMのセマンティクスに最も単刀直入なマッピン グを提供する言語なのです。JVM上でのアプリケーション記述により適した言語として、Scala、Ruby、Groovy、Pythonなど多数が存在 しますが、必要最小限の「恐ろしく高速な」ライブラリやフレームワークのコード記述に関しては、いまだにJavaが王様です。この状況が近いうちに変わる ことはないでしょう。
InfoQ：Rubyコードの利用目的で、パースツリーや他のソリューションではなくJRubyを使うメリットをお話しいただけますか。Nutterさんならどうやって、JRubyやJRubyParserを使うよう、Schmerderさんを説得できたのでしょうか。
Nutter氏：えー、私の無知を白状しなくてはなりませんね…何しろ、ABAPの機能の仕方を実は知らないもので。新しいJRubyParserプロジェクトは元来、派生プロジェクトでしたので、外部のJRuby消費者 -- ほとんどはNetBeansやRadRails、3rdRail のようなIDEプロジェクトでしたが -- が、JRubyの動きの速い開発プロセスから独立して、コードベースに協力できました。こうした消費者には、JVM向けのより優れたRubyパーサライブ ラリを構築する自由を与えたかったのですが、それと同時に、そのパーサとASTを私たちの手で自由に修正して、より優れたパフォーマンスと、JRubyで のメモリフットプリントの小型化をサポートできるようにしたかったのです。
JRubyParserがSchmerderさんとBlueRubyに 役立つのは、ABAPコードと並行してJavaを動作可能な場合に限られると思います。しかし、正直に言えば、ruby_parserを使うという Schmerderさん達のアプローチはすばらしいと思います。Ryan Davis（ruby_parserのクリエータ）がライブラリに多くの時間と多大な労力をつぎ込んだことを私は知っていますし、優れたAPIと高度に標 準化されたアウトプットをもたらすので、私自身のプロジェクトで使いたいと思っています。恐らくCやJavaベースのパーサほど高速ではないでしょうが、 その点はBlueRubyでは心配しなくてよいでしょう。
InfoQ：JRubyはかなり成熟したプロジェクトですが、開始以来、どれほどの延べ年数が費やされたかご存じですか。準備中の次の機能、重要な課題は何ですか。プロジェクト初日と同じぐらいのやる気がまだありますか。
Nutter氏：JRubyは確かに成熟しています。プロダクション段階に入る用意が整って1年以上経ちますし、代わりとなる他のどのような実装も、まだ このマイルストーンには到達していません。政府、通信業者、公共事業者、その他の多数がJRubyアプリケーションを使っています。延べ年数に関しては… お伝えするのは難しいですね。JRubyのコミッター全員が長期間に渡って、1日8時間以上を費やしていますが、実のところ、好きでやっている仕事です。 JRubyには恐らく非常に多い延べ年数を費やしており、今でも非常に速い速度で前進しています。それに加え、JRubyがGoogleの AppEngineに取り組むと今週発表があったように、JRubyがRubyistに今後も新しいチャンスを与えると考えています。JVMが、言語とアプリケーション開発向けの選りすぐりのプラットフォームであることに疑いの余地はなく、今目にしているのはほんの出発点にすぎないのです。
InfoQ：Nutterさん、SchmerderさんのVM実装に関してSchmerderさんに聞いておきたいことで、読者のためにもなる質問はありますか。
Nutter氏：Rubyの機能の中で、これまでに実装が一番難しかったのは何ですか。
Schmerder氏：うーん、難しい質問ですね。現時点では単にサポートしない機能（ネットワークソケット、スレッド、C-libなど）がありますが、 その理由は、ABAP VMでは公開されている同等の機能がないからです。メソッドをディスパッチさせ、例外の処理を正しく行うまでには多数のイテレーションをこなさなければな らなかったのですが、今ではあと少しのところまで来ています。ほとんどの作業はもちろん型システムであり、不幸にもそれは一番面白くない部分でもあるので す。公開することで、ここの進行を速めなければならなくなります -- それはとても難しいというわけではなく、私たちは研究者なので、String#fct2500の実装にはあまり興味がわかないのです。
Nutter氏：BlueRubyのオープンソース計画はどうなっていますか。コミュニティ開発者が貢献可能なのでしょうか。
Schmerder氏：私個人としては、Blue Rubyのオープンソースライセンスによるリリースを、SAPがいつか許可してくれるよう願っており、それに向けて努力しています。しかし、SAPはオー プンソースでのリリースに経験が浅く（Rubyコミュニティで新参者であるように、オープンソースの分野でもビギナーなのです）、従来のABAPアプリ ケーションのライセンスとオープンソースの構成要素をミックスできる方法を、SAPの弁護士は見つけださなければなりません -- なぜなら、ABAPアプリケーションがなければ、Blue Rubyはまったく無意味だからです。ですから現在のところ、私は何も約束できません。しかし、トライアルプログラムを始めたばかりで、参加に興味を示し ているSAPパートナーが多数存在します。このトライアルプログラムの結果によって、私たちの優先事項が必ず押し進められることになるでしょうし、パート ナーもさらに積極的に関与できるようになるでしょう。トライアルは専用のトライアルライセンス契約に基づいているので、より大規模なコミュニティに拡大さ れることはありませんが、それでも、きっかけにはなります...
Nutter氏：Rubyを動作させるということに関して、ABAPの長所は何だとお考えですか。最も弱い分野はどこと思いますか。
Schmerder氏：そうですね、ABAP環境について語れる良い点はたくさんあります。それ自体が企業アプリケーションサーバーなので、スケーラビリ ティやデプロイメント、ユーザーアクセス管理などといったたくさんの事柄を心配する必要がありません。そしてアプリケーションサーバー全体の最大の長所 は、既存のアプリケーションです -- SAPはほとんどどんな国でも、どんな産業でも、ビジネスプロセスのあらゆる側面（財務会計、HCM、CRM、 SRM、SCMや、私がここでリストアップを忘れたあらゆる分野）を網羅します。Blue Rubyを使えば、これまでに書かれた3億行近いABAPコードにローカルでアクセスできるようになります。そして、最新の効率的な言語を使って、システ ム内に存在するこうしたアプリケーションの消費や改変、拡張が可能になります。
マイナス面として私たちが毎日経験しているのは、ABAPが他のVMの実装向けのホスト言語ではなく、ビジネスアプリケーションの記述を意図されて いたということです。そして、Javaとは違い、いまだにビジネスアプリケーションの記述を目的としていて、（Javaに関するNutter氏のつぶやき を借りれば）「ABAP-VMのためのC」には進化を遂げていません。ですから、ABAPには別の方法がないため、互換性の理由から、時には非効率的な （＝遅い）実装を使わなければなりません。ABAPはJITコンパイルのないバイトコードと翻訳されるので、インタプリタ内に別のインタプリタを実際に走 らせることになります。常にコードをリファクタリングして互換性問題を修正したり、より良い方法を試そうとしたりしているので、ABAPのツールにはリ ファクタリング向けのサポートが欠如していることも、経験上わかっています。調整しているとさらに長時間を要するという理由から、結局、大部分をゼロから リライトすることになってしまいます。
しかし、言語をその意図された目的以外に使っているのですから、こうしたものを「ABAPの弱点分野」と呼ぶのはフェアではないでしょう。ある意味、この 言語を乱用しているのですから、その欠点について不平は決して口にしません。「研究している」と常に言い聞かせるのです。:)