Skip to main content
Version: 1.0 (alpha)

Providers

Overview​

A provider fulfills a non-functional requirement (sometimes called a capability): some functionality that is not considered part of the core business logic, such as...

  • 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. If you were to write this web service in a component, you would depend on providers to fulfill HTTP and database funcionality in order to execute your business logic.

In wasmCloud, 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 components is available.

Capability Contracts​

info

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 components 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:

  • wasmcloud:builtin:numbergen
  • wasmcloud:builtin:logging

The list of capability providers continues to grow. Please refer to these links for more information:

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 wasmcloud:-prefixed IDs.

Deny-by-default Capability Access​

Not every component should be able to access every capability. Securing and restricting communication between components and providers is important to avoid components gaining access to capabilities they should not have access to.

To contact a particular capability provider, a component must:

  • be signed with a the appropriate capability contract ID, which happens automatically during the component build process
  • be linked at runtime to the capability provider