Mozillaは今週、WebAssemblyコードとオペレーティングシステムの相互作用を標準化するWASI（WebAssembly System Interface）プロジェクトを発表しました。このプロジェクトが成功すれば、OracleのJava仮想マシンと同様の機能を、より優れた形で、より広範囲に実現できるようになります。
WebAssembly（WASM）は、複数のハードウェアアーキテクチャで実行可能な仮想マシン用のバイナリ形式です。WASMコードは、C/C++、Go、Rustなどの様々なプログラミング言語からコンパイルターゲットとして生成できます。
WebAssemblyはすべての主要なウェブブラウザで採用されていますが、ブラウザ外で実行するための標準的な方法はまだありません。そこでWASIが登場します。
「ブラウザ外部のコードには、システムと通信する手段、つまりシステムインターフェースが必要です」と、Mozillaのソフトウェアエンジニアであるリン・クラーク氏はブログ記事で説明しています。「そして、WebAssemblyプラットフォームにはまだそれが備わっていないのです。」
WASMってどうなってるの？
WASIにより、WASMコードはブラウザや準拠した環境で実行できるようになり、言語に依存しないクロスプラットフォームアプリケーションの展開が可能になります。Portable Operating System Interface (POSIX) がUnix系オペレーティングシステム間でソースコードを移植可能にする方法を提供するのに対し、WASIはコンパイルされたバイナリをデバイスやオペレーティングシステム間で移植可能にすることを目指しています。WASIは、ネイティブに近い速度で動作するユニバーサルランタイムを実現します。
Java仮想マシン（JVM）も同じ目的を果たしますが、プラグインなしではブラウザでJavaコードを実行することはできません。WebAssemblyプラットフォームが提供する言語の柔軟性は、GraalVMを介してJavaでも実現できるかもしれませんが、Javaエコシステムはオープンであるにもかかわらず、依然としてOracleとそのJava関連IPに対する主張の影に隠れています。
WASMはメモリセーフで検証用に調整されているため、Javaアプレットよりもセキュリティ面で優れていますが、制御フローハイジャックの脆弱性が残る可能性があります。また、C/C++やRustなどの言語との互換性も優れています。
Mozilla の WebAssembly チームを管理する Till Schneidereit 氏は、Twitter で WebAssembly と Java の違いを次のように説明しました。「WebAssembly は、小型デバイスから大規模なサーバー ファームや CDN にまで拡張できるように設計されており、Java よりも言語に依存せず、実装フットプリントもはるかに小さくなっています。」
ああ、すっかり成長したね: Mozilla が WebAssembly を家具の少ないワンルームマンションに移動
続きを読む
WASIの潜在的な重要性がまだ明らかでないなら、Dockerの共同創設者であるソロモン・ハイクス氏の発言を考えてみてください。「もしWASMとWASIが2008年に存在していたら、Dockerを作る必要はなかったでしょう」と彼は言います。「それほど重要なのです。サーバー上のWebAssemblyはコンピューティングの未来です。標準化されたシステムインターフェースが欠けていたのです。WASIがその役割を果たしてくれることを期待しましょう！」
この楽観的な見通しの波に乗り、CDN企業のFastlyは木曜日に、エッジクラウド環境でWASMコードを実行するためのネイティブWebAssemblyコンパイラ兼ランタイムであるLucetをリリースしました。これは、ブラウザ外でWASMコードを実行するためのMozillaのランタイムであるWasmtimeを補完するものです。
WASIが完全に完成するまでには、まだ多くの作業が必要です。WebAssemblyも、ブラウザのDOM（ドキュメントオブジェクトモデル）へのアクセス機能など、さらなる改良の余地があります。しかし、一度書けばどこでも実行できるバイナリは、価値のある取り組みです。それまでの間、Javaをお楽しみください。®
