Wasm: What Is The Component Model
In the beginning of this year the WASI preview 2 reached a milestone by being launched.
It got enabled by two things: the WIT IDL and the component model. Let’s check in this post what it is.
From the WASI repository:
WASI Preview 2 represents a major milestone for WASI. It marks the moment when WASI has fully rebased on the Wit IDL and the component model type system and semantics, making it modular, fully virtualizable, and accessible to a wide variety of source languages.
Principles of the component model
Some things to know about the component models are:
- It’s a Wasm standard.
- A component is exporting inner interfaces or importing outer interfaces by other components.
- The interfaces of components are written in the WIT interface definition language:
package dkwr:stringlength@0.1.0;
interface len {
len: func(s: string) -> u32;
}
world string-operations {
export len;
}
- In the end, a component is a
.wasmfile. - A component is also called world.
- It’s an agreement on interfaces by which components can be composed.
- Before the component model Wasm was interoperable between architectures and operating systems. Now, Wasm is interoperable between languages.
- Components are communicating with a runtime or other components by calling its imports and having its exports called.
- Indirect communication to other components by writing to its memory and having others read from that memory is not possible, unlike in core modules.
The goals
The goals of the component model are:
- Reinforcing sandboxing.
- Enable interoperation between languages that make different assumptions about memory - for example, allowing a component that relies on Wasm GC (garbage collected) memory to collaborate with one that uses conventional linear memory.
- WASI builds upon the components and releases a first set of components. This makes it cross-language and virtualizable.