Skip to main content

Glossary of Terms

Definitions for frequently used terms

wasmCloud​

wasmCloud is the CNCF-owned open source project that Cosmonic builds on top of. 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. Anything you build that works in plain wasmCloud should work automatically in Cosmonic!

Host​

A host is a distributed, resilient, highly performant wasmCloud runtime process that manages actors and capability providers. Hosts coordinate the scheduling of compute, emit events, manage observability and tracing, and participate in a constellation network.

Actor​

An actor is a small WebAssembly module that can handle messages delivered to them and invoke functions on capability providers. 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 actors 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 actor 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 actors to pick and choose implementations based on convenience, requirements, and environment. An actor 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.

A link definition is a runtime defined connection between an actor and a capability provider. Link definitions inform the host runtime about what capability providers an actor may invoke. Link definitions can be removed and added at any time. An actor 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.

Constellation​

A constellation is a managed, isolated network space that allows your actors and providers to securely communicate with each other regardless of physical or logical location. You can think of a constellation as a Cosmonic-managed wasmCloud lattice.

Wormhole​

A Wormhole is an ingress point into your constellation. It exposes a single actor through a special wormhole-aware web server capability provider on a randomly generated DNS name like fuzzy-lake-1234.cosmonic.app. Resources are not accessible on the public internet by default and must be explicitly allowed entry.

Today, wormholes support exposing endpoints with the HTTPS protocol. Additional protocols like TCP, NATS, gRPC, etc. may be added in the future.

Auctions​

Throughout documentation and tutorials, you may see the term auction. When seeking potential candidates for a deployment of a capability provider or an actor, you can perform an auction. An auction will send a request out to the entire constellation for all hosts matching the criteria supplied. The "winners" of this auction are then considered suitable candidates. Managed applications rely heavily on auction functionality.

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 actor.

Infrastructure View​

The infrastructure view is a perspective into your constellation that shows the virtual hosts running in your constellation. Here you can see the hosts, their associated metadata, as well as the contents of each host.

Logic View​

The logic view is a perspective into your constellation that shows the logical relationships between components. Here you can see actors, providers, links, and wormholes all without regard to the underlying infrastructure. The logic view can even span multiple disparate infrastructures connected via super constellations.

General and Ecosystem Terms

The following is a list of terms that you might encounter in Google searches that are part of the ecosystem of technology used by Cosmonic and wasmCloud.

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.