Glossary
The following is a list of common terms in the ecosystem of technology used by Cosmonic and wasmCloud.
wasmCloud
wasmCloud is the CNCF-owned open source project that Cosmonic builds on. It is a distributed platform for writing portable business logic that can run anywhere from the edge to the cloud. Most of the other terms in this glossary derive from terminology used by wasmCloud.
Host
A host is a distributed, resilient, highly performant wasmCloud runtime environment that manages components and capability providers. Hosts coordinate the scheduling of compute, emit events, manage observability and tracing, and participate in a distributed network.
Component
A component is a WebAssembly binary conforming to the WebAssembly Component Model. Components are:
- Small and portable, with file sizes ranging from kilobytes to megabytes
- Interoperable, able to communicate via language-agnostic interfaces with any other component—regardless of the language the other component was written in
- Composable, so that multiple components can be combined into one
When you write an application with Cosmonic, the code that you write will be low-boilerplate logic that interacts with capability interfaces to create your fully functioning application.
Developing with components allows you to focus on writing the right code without tightly coupling to architecture, scale, or non-functional requirements.
Capability
A capability is an abstraction or representation of a non-functional requirement: some functionality required by your application that is not considered part of the core business logic. Capabilities both describe functionality (for example, an HTTP Server receives requests and returns responses via TCP) and are used to verifiably allow application components to access resources. Capabilities are deny-by-default and must be explicitly granted for each component that wishes to use that functionality. You can read more about capabilities in the wasmCloud capabilities documentation.
Capability Provider
A capability provider is an implementation of the abstract representation described by a
capability contract. Capability providers and capabilities have a many-to-one relationship; a
single capability contract can have multiple implementations, and as such provide the ability for
components to pick and choose implementations based on convenience, requirements, and environment. An
component that declares a wasmcloud:keyvalue
capability can, for example, pick the
Redis provider for
simplicity, a
HashiCorp Vault provider for
secrets management, or even the Cosmonic built-in key-value provider for a fully hosted key-value
store.
Link Definition
A link definition is a runtime defined connection between a component and a capability provider. Link definitions inform the host runtime about what capability providers a component may invoke. Link definitions can be removed and added at any time. A component that was previously linked to one implementation of a capability can change to another implementation or an updated version of that capability provider without requiring a redeploy or a recompile. Link definitions can also include configuration information, such as database connection strings, port numbers, or API access keys.
Capability providers are launched with a link name that acts as a way to allow different link
configurations for the same capability provider. For example, you can launch two NATS capability
providers with different link names, frontend
and backend
, and traffic can be segmented between
two sources based on link name. The wasmCloud SDK assumes the default link name, default
, and if
you launch capability providers on different link names then you'll need to specify that link name
with the provider sender in your code.
OCI Reference
The Open Container Initiative (OCI) has defined a standard by which artifacts can be stored, retrieved, and distributed. This standard is called OCI distribution. Many well-known applications support OCI, but the ones you may see most often in Cosmonic and wasmCloud documentation are the Azure Container Registry and GitHub artifact registries.
OCI references are URLs that point to such artifacts, e.g. wasmcloud.azurecr.io/echo:0.3.2
is the
URL for v0.3.2
of the wasmCloud example echo
component.
WebAssembly
WebAssembly is a standard that defines a compact, stack-based virtual machine. You can think of this as being in the same family as the bytecode machines used by Java or the .NET runtime. However, what makes WebAssembly so powerful (and so amenable to the cloud!) is that it is secure by default, truly portable, and incredibly small — all the things we want in a cloud deployment target.
WASI
WASI is an acronym that stands for the WebAssembly System Interface. WASI is a
modular system interface originally designed around the ideas of security and portability. It
provides some low-level system functionality (like stdio
and limited file access) to otherwise
isolated WebAssembly modules.
This standard is undergoing a lot of advancement and there are a lot of really amazing things on the horizon that are either part of WASI or tangential to it. Stay up to date on all the developments by following our blog.
Component Model
The WebAssembly Component Model is an evolving standards effort that has the goal of making it easier for multiple WebAssembly modules to interact with each other. As usual, when there are developments in this ecosystem related to our work at Cosmonic, we will be blogging about it.
Key-Value Store
A key-value store is an incredibly popular persistence mechanism. Rather than requiring tables, joins, foreign keys, and SQL queries, a key-value store gives you atomic access to individual values. The data stored within a key can be simple strings, JSON payloads, sets, and more. Cosmonic provides a built-in key-value store accessible to all customers.
NATS Leaf Node
A NATS leaf node extends a NATS system of any size, bridging infrastructure together and routing messages between local nodes and an upstream network as needed. We use leaf nodes to extend the Cosmonic network anywhere.