WebAssembly Component Modelは、WebAssemblyの複数unitを明示的なinterfaceで接続するためのlayerです。Core moduleの実行構造と、componentが言語間で公開する高水準の契約を区別します。WIT定義はinterfaceとworldを、Wasm 3.0の案内はCore機能の範囲を説明します。

Core moduleとcomponentは別のlayer

Core moduleはfunction、memory、table、import/exportなど低水準の実行構造を定義します。Core 3.0には単一module内の複数memoryや、より豊かなreference typeが含まれます。Wasmを「memoryが常に一つで数値型だけ」と説明するのは現在の標準に合いません。ただし標準機能が、すべてのbrowserやserver runtimeで同じversionとして使える証明にはなりません。

Component ModelはCore moduleや他のcomponentを高水準の契約でまとめます。WITのinterfaceはfunctionとtypeを集め、worldはcomponentが必要とするimportと提供するexport全体を記述します。接続時にはnameだけでなくtypeとimportの互換性を確認します。

WITでplugin境界を設計する

logを正規化するpluginを考えます。hostはlog.write(message)のようなfunctionをimportとして提供し、pluginはnormalize(record)をexportできます。実装言語は選べても、呼び出し側はWIT契約に基づいて接続します。この契約はhost機能が自動的にすべて使えるという意味ではありません。file、network、clockへのアクセスはhostがimportを接続し、runtime policyが許可した場合に限られます。

小さなinterfaceは必要なcapabilityをレビューしやすくしますが、それだけでsecurityが完成するわけではありません。hostが強すぎるfunctionを提供したり、入力検証が不足したりすればriskは残ります。authorization、dataサイズ、error処理、resource budgetはhost側で設計します。

deployment前にtoolchain互換性を確かめる

Component Model binaryとWITを扱えるかは、Core .wasm moduleを実行できるかとは別の互換性確認です。compiler、component linker、配布先runtimeが必要なModelとWASI version・typeを扱えるか調べ、実際の配布先でimport/exportをlinkするtestをします。WebAssembly projectのFeature Statusは主要engineやtoolの実装状況を追跡しています。specに記載されているだけで対象runtimeの対応を推測しないでください。

Component Modelが特定のperformanceや完全なsecurity isolationを一律に保証するわけではありません。実際のworkloadで境界変換と呼び出しcostを測り、選択したruntimeとhost設定のsandbox・capability policyを確認します。

小さな接続test

plugin導入前にWIT worldのimport/exportを読み、一覧を作ります。hostが必要なimportだけを接続しているか確認し、正常record、不正入力、大きすぎる入力、import未接続をそれぞれ試して契約どおりの値とerrorになるか見ます。最後にdeployment先runtimeで同じcomponentをloadし、開発環境との差を確認します。

参考資料