A capability is an abstraction over a non-functional requirement, some functionality that is not considered part of the core business logic. Actors depend on capabilities to fulfill their business logic, and these capabilities are provided by — you guessed it — capability providers.
Some examples of non-functional requirements you might be familiar with:
- Sending notifications
- Fetching secret values
- Accessing Databases
- Serving content over HTTP
For example, when writing a web service that exposes a RESTful API, the HTTP server and the database are not parts of your business logic -- your primary concern is structuring your API so that users can easily get the data they need.
The following section was written before WASI Preview 2 was stable. wasmCloud supports wasi-cloud-core interfaces, the existing
wasmcloud:* interfaces, and custom interfaces written by third parties.
Capability contracts specify the required functionality for a given capability -- forming an interface or service abstraction that actors can rely on.
Capability contracts are identified with IDs -- unique names that identify an interface or service abstraction.
Capbility contract IDs in wasmCloud contain a vendor ID prefix (the vendor that defines the contract, not necessarily a specific implementation).
For example, the following is a list of some capability contract IDs supported by wasmCloud:
In addition to on-lattice providers, some capability contracts have implementations that are built-in to the wasmCloud host:
The list of capability providers continues to grow. Please refer to these links for more information:
- first-party providers - a list of supported capability providers
- interfaces - definitions of several api specifications, many of which are capability contracts
- example providers - additional sample code
Capability contracts (and their associated IDs) are open, and any organization is free to create implementations of them.
We believe a healthy wasmCloud ecosystem includes multiple implementations of capability contracts from multiple vendors, including those with
In wasmCloud, capability providers are self-contained processes that implement a capability contract, which corresponds to a well-defined API.
Capability providers run on your wasmCloud lattice, and ensure that functionality depended on by actors is available.
Deny-by-default Capability Access
Not every actor should be able to access every capability. Securing and restricting communication between actors and providers is important to avoid actors gaining access to capabilities they should not have access to.
To contact a particular capability provider, an actor must: