WebAssembly components play a key role in runtime deployments that run inside the WebAssembly module. However, its standardization is still a work in progress.
Translated from what is a webassembly component?The Ultimate Guide, by B cameron gain。WebAssembly components play a key role in the deployment of runtimes that are located inside the WebAssembly module. However, its standardization is still being developed.
Once finalized, the component model will allow WebAssembly not only to extend its use beyond web browsers and servers, but also to allow users to deploy different applications running within numerous lightweight modules simultaneously and at extremely high speeds on thousands of endpoints through a component interface called WebAssembly System Interface (WASI), without any changes to the WebAssembly. This is at least theoretically, but at the same time, the community is working hard to make it happen. At the same time, there is a lot of confusion about what a component is and how it affects the adoption of WebAssembly. Before we dive into what a component is and what it does, we first need to describe what WebAssembly is and how its evolution has led to the need for a component model, specifically how it relates to WASI, a standard interface or API that links web assembly modules to components. WebAssembly is designed to deploy applications written in the language of the developer's choice for simultaneous deployment in a variety of different environments. "Different" here means that WebAssembly runs on the CPU, only the device, server, etc., that can run the CPU instruction set. This means that application deployments in a single WebAssembly module should theoretically be able to run and update on many different devices, including servers, edge devices, multi-cloud, serverless, and so on.
As long as there is a CPU capable of running instruction sets, WebAssembly is designed to run a growing number of applications written in languages that it can host in modules. It can now accommodate Python, J**Ascript, C++, Rust, etc.
Different applications written in different programming languages should be able to coexist within a single module, although this functionality is still being developed at scale.
Essentially, a module full of microservices should be able to deploy multiple services in a variety of environments and bring up program updates without having to reconfigure the endpoint.
Theoretically, it's just a matter of configuring the applications in the module so that each environment in which the module is deployed doesn't need to be reconfigured individually after the work is done within the module. However, it also depends on the finalization of the component standard.
Now, as we've observed in kubernetes and docker, the desire to deploy applications everywhere at the same time depends on a standardized component model.
This model is often compared to a Lego block. These components provide an interface to the runtime through WASI as a web assembly module. These components are stacked on top of each other, linking them together to take advantage of the commonality and utility of the various WebAssembly runtimes to form a unified package or unit made up of components.
The beauty of this approach is the security it provides, just as Kubernetes ensures that components don't share data in memory, namespaces, or namespace allocations. They maintain a closed or sandbox interface through the WebAssembly bot module. However, achieving standardization is a challenge;Making components run on any system is the goal. This will allow the Web Assembly module to interact seamlessly with the component, deploy and run on the CPU instruction set. While it's configured to do this for any module that follows the standard, this standard is still a work in progress and represents the last mile of the WebAssembly journey.
Currently, component development plays a key role in the open source community's efforts to advance WebAssembly. Standard component interfaces are being built in an innovative way that heralds a world of infinite possibilities.
Many open source projects and research initiatives are contributing to this finalization process. For developers, especially those like Kubernetes, the inner workings of component development may not be of much interest. They primarily seek the end result: the ability to deploy applications as they want as WebAssembly becomes more integrated with Kubernetes. This may remind you of the advent of DOS in the 80s and 90s of the 20th century, when a plethora of books delved into file interaction, configuration, and DOS commands. However, for most programmers and software engineers, understanding these complexities isn't critical, especially given the dominance of UNIX and Linux in the software development landscape.
In his keynote at Wasmcon in September, Luke Wagner, a distinguished engineer at Fastly, who places a high value on WebAssembly in some of the services of its edge delivery platform, described in one sentence what a wasm component is: an emerging, standard, portable, lightweight, finely sandboxed, cross-language, and composite module. He explained that a component is a module that contains imports, internal definitions, and exports. Imports include elements such as imported functions (e.g., log functions) and typically capture the IOs provided by the component and their implementation dependencies, rather than relying on a fixed set of system calls or a fixed runtime global namespace.
The internal definition represents the running core**, which consists mainly of embedded wasm modules, "where 99% of the bytes are stored." Internal definitions can also be called imports," Wagner said.
Components can be further nested with other components, making them recursive in nature," Wagner said. Finally, the export makes the internal definition and import of the component exposed to the client by assigning values to the name and type. ”
In the container world, the Open Container Interface (OCI) defines the standard for distributable containers. The docker build creates the container from the source, the docker run and kubernetes run and deploys it for sharing and composition, and docker push and docker composition come into play, Wagner said. So a natural question arises: can we use wasm for this purpose?Wagner asked. "It's undoubtedly a standard distributable format, but the challenge is that wasm primarily supports shared memory links. When we want to link two wasm modules together, they usually need to share memory to pass composite values through that shared memory, which is similar to the DLLs or shared objects of the operating system. ”
However, when combining two or more webassembly modules, they should keep their own separate memory, which is not shared, Wagner said. There needs to be a way to pass complex values and transfer ownership between them, which cannot be copied between them, similar to an operating system executable, he said.
Is it possible to encapsulate the wasm module with a Portable Operating System Interface (POSIX) to create the wasm executable?
Distributing a single POSIX executable is often not enough, as we often need to distribute a set of executables that must work together, as well as configuration files, static assets, and directory structures, Wagner says. One solution, Wagner said, might be to put the wasm module into a container with the wasm as the core instruction set.
While this approach could be useful, it doesn't unlock the exciting new use cases we envision," Wagner said. "To achieve this, we needed something new, a wasm wrapper that would allow us to use existing compilers. We are coming up with this new concept and called "components". ”
It must be borne in mind that the business model is being built on WebAssembly due to its unique features, which largely depends on the finalization of the component model.
Wagner said that there have already been developers who have chosen Wasm to "run ** that would otherwise not work", which led us to build a set of reusable tools to support the first wave of languages and APIs. But because these tools aren't just coupled to a platform, they often use a component model, and now we can attract a new wave of platform builders who are leveraging this meta-ecosystem and getting a lot of things that they don't have to build themselves," Wagner said.
This could appeal to a new generation of developers who are currently choosing WebAssembly because of its ease of reuse and increased productivity across all these reusable components. This can then lead us to build a whole new set of tools that allow us to compose applications from components and create a whole new model of developer programming. ”
It's important to keep in mind that, due to its unique capabilities, various business models are forming around WebAssembly, and a large part of that depends on the finalized component model.
Currently, developers choose to use WebAssembly in order to "run things that would otherwise not work," as Wagner emphasizes. This led to the development of a suite of reusable tools designed to support the first wave of languages and APIs.
Because these tools are not tied to a single platform, they are widely based on a component model. As a result, a new generation of platform builders has entered the space, leveraging this meta-ecosystem and gaining access to a lot of resources that don't have to be developed from scratch.
As a result, a new generation of developers is drawn to WebAssembly, attracted by its ease of reuse and the high productivity it provides through these reusable components. This, in turn, led to the development of a new set of tools for combining applications from components and creating an entirely new developer programming model.
Wagner said that a formal specification is being developed that includes operational semantics, a reference interpreter, and a reference test suite. The use of bindgen and wasm tools has been implemented for a large part of the wasm time. An important milestone expected to be reached early next year is components that are synchronized with fully parameterized links, values, resources, and handle types.
The major subsequent milestone is the addition of futures and processes to the component model, the introduction of asynchronous support. "It's going to be a challenging step, but it's going to simplify a lot of work that would otherwise need to be done repeatedly," Wagner said. Finally, there are some remaining elements that need to be done with the MVP of the component model, such as optional import and export. ”