WebAssembly (略して Wasm) は、ネイティブに近い高速な実行速度、プログラミング言語の選択肢の多様さ、およびデフォルトで拒否する堅牢なサンドボックス モデルにより、革命的なテクノロジーとして何度も実証されてきました。 すでに Web 全体で広く使用されており、サーバー側でも強力なプレーヤーとなっています。
成長著しいエコシステムには、すべての要素がどのように組み合わされるかというビジョンが必要であり、まさにそこでWebAssembly コンポーネント モデルの出番となります。 コンポーネント モデルは、WebAssembly コードの個々のユニット間の相互作用と、WebAssembly コードとホスト環境間の相互作用を容易にするシステムです。 これらはすべて、WebAssembly コンポーネントの概念を中心に展開されており、基本的にはエンコードされたデータ型を持つ通常の Wasm モジュールです。 これらの型により、コンポーネントがシームレスに相互通信できるようにするバックグラウンドの接着コードの生成が可能になります。
コンポーネント モデルは、現代のソフトウェア開発の新しい時代を切り開きます。開発者は、任意のプログラミング言語エコシステムからコンポーネントを選択して、単一のアプリにまとめることができます。Python でデータ処理アプリを作成していますが、Rust の効率的なパーサーが必要ですか? 問題ない。 組織内の 1 つのチームは Go に精通していますが、別のチームは JavaScript しか書きません。 まったく問題ありません。各チームは、手間をかけずに構成できる WebAssembly コンポーネントを作成できます。
WebAssembly は、ほぼすべての新しいコード実行プラットフォームで見られる問題に直面しています。つまり、完全に異なるプログラミング言語ツールチェーンによって生成される可能性のある個別のコード ユニット間で、データを安全かつ確実に、効率的に共有するにはどうすればよいかということです。 一般的に、2 つの個別の WebAssembly モジュールは、多くのシステムと同様に、JSON、Protobuf、またはその他の一般的なデータ交換形式でモジュール間でデータを渡すことができます。 これらの形式のシリアル化とデシリアル化はかなりコストがかかります。結局のところ、相互に通信する 2 つのモジュールは、ネットワーク経由ではなく、同じランタイムによって並行して実行される可能性が高いため、この実装の方が優れている可能性があります。
問題は、各プログラミング言語がデータを表現する方法にあります。 言語の実装では、文字列に異なるエンコーディングを使用することを選択する場合があり、ある言語では順次データを配列として保存することを好む一方で、別の言語ではリンク リストを好む場合があります。 異なる言語のコードが相互に通信できるようにするには、すべてのタイプのデータに対して共通の形式に同意する必要があります。 これはapplicationバイナリ インターフェイス (ABI) として知られています。実際には、どれも一致しません。 通常、ある言語で書かれたコードを別の言語で書かれたコードと通信させたい場合、気の毒な開発者が座って、2 つの言語間で変換するコードを慎重に (そして苦労して) 書かなければなりません。 両方の言語がどのように機能するかについての詳細な知識が必要であり、エラーが極めて発生しやすくなります。 一部の言語エコシステムでは、これを自動的に実行できるツールを作成できましたが、それでも、それは特定の言語に限られます。
ありがたいことに、コンポーネント モデルは、標準ABI と呼ばれるすべての言語に共通のデータ形式を定義します。人間にとって物事を簡単にするために、コンポーネント インターフェイスを記述するための WebAssembly インターフェイス タイプ (WIT) と呼ばれるインターフェイス定義言語も存在します。
これらすべてのコンポーネントが揃っていますが、どこで使用できるかはどうすればわかるのでしょうか? 結局のところ、WebAssembly は、Web ブラウザー、サーバー、エッジ、小型デバイスなど、さまざまな場所で実行され、それぞれ機能が異なります。 WIT は世界の概念をもたらします。 ワールドとは、コンポーネントが準拠するインターフェースであり、コンポーネントがインポートできる関数のセットと、コンポーネントがエクスポートする関数のセットです。 これにより、コンポーネントとその構成について簡単に推論できるようになります。 以下は、ターミナルのコマンドラインで実行されるコンポーネントを記述する、`wasi:cli/command` の世界に存在するコンポーネントの定義です。
ソース: https://github.com/WebAssembly/wasi-cli 、簡潔にするために修正
このコンポーネントは、ファイルシステムやランダム性などを考慮しながら、入力と出力のストリームも備えていますが、重要なのは、コマンドが呼び出されたときに実行される関数を提供することです。
ワールドは誰でも定義できますが、HTTP リクエストの処理、USB デバイスへのアクセス、AI モデルの使用などができるコンポーネントの標準化されたワールドが多数存在し、今後もさらに増えていく予定です。 ホスト環境では、実装するワールドをアドバタイズして、開発者がどのコンポーネントが機能するかを簡単に把握できるようにすることができます。 コンポーネントは構成可能であるため、一部の世界を他の世界の観点から実装し、2 つのコンポーネントを構成することも可能です。 たとえば、ソケットの世界を実装するホスト環境があり、HTTP の世界で HTTP リクエストを行うコンポーネントがある場合、ソケットを使用して HTTP の世界を実装するアダプター コンポーネントを作成できます。
シンプルな構成により、コンポーネントは変更なしでソケットの世界で実行できるようになりました。 可能性は無限です。
コンポーネント モデルは、WebAssembly だけでなく、あらゆる場所のすべての開発者にとって重要です。 これにより、開発者がソフトウェアについて考え、開発する方法が根本的に変わります。すでに多くのユーティリティが存在しますが、まだ初期段階です。 WebAssembly エコシステムで起こっている開発に引き続き注目してください。採用が拡大するにつれて、ますます魅力的なユースケースが生まれるはずです。