Capability-based programming

Capability-based programming is a concept that is closely related to Interface-based programming where each interface is assigned a globally unique identity and represents a small concise feature. It is one approach to software development for the Internet of Things.
Overview
Capability-based programming is a software development methodology that is closely related to Interface-based programming, where each interface is assigned a “practically” globally unique identity and defines a small concise feature. These interfaces, also known as Capabilities, are implemented by objects and may be exposed to the network as discrete endpoints, allowing consumers to identify, address, and access individual features of an object. Capability-based programming allows clients to be written against a set of features (capabilities) without any binding to an implementing object. Thus, allowing any object that implements the set of features (capabilities) required by the client to be used by that client and for the object to be replaced at runtime.
Origins
Capability-based programming was first described by the Society of Motion Picture and Television Engineers (SMPTE) Ad hoc Group on Media & Device Control over Internet Protocol Networks in September 2010 to address the requirements of media and device control applications within heterogeneous systems, such as the Internet of Things.
Capabilities
A capability is an interface that has a “practically” globally unique identify that typically defines the behavior for a small concise feature. For compatibility with legacy systems and existing interface definitions capabilities may also represent more complex behaviors, however, the benefits of Capability-based programming are derived from using capabilities as building blocks to model complex object behaviors, in much the same way as toy plastics building blocks are used to construct larger plastic toys.
In networked applications, such as the Internet of Things and SMPTE ST2071,<ref name="SMPTE ST2071-1"/> capabilities are exposed a discrete endpoints and are not consolidated into a single service definition, a common practice with Web Service endpoints. This is due to the dynamic nature of capabilities and allows the implementing objects to alter there exposed behavior dynamically, on the fly, without breaking interoperability.
Capabilities are similar in many ways to Microservices, however, multiple capabilities can and should be exposed by the same object and/or process.
Unique identification and addressability of features
The idea of uniquely identifying and addressing features, independent of the objects implementing them, was first presented in the initial development phases of the SMPTE ST2071 standard. After the standards committee had inverted a traditional object model and had discovered that the objects were simple aggregations of related features and that many objects shared the same features, just in different arrangements. It was determined that the features could be decoupled from the objects implementing them, provided each feature was uniquely identified and provided an independently addressable endpoint or exposure to the system/network. These uniquely identified features became known as Capabilities.
Features (Capabilities) as a First-Class Citizen - Decoupling features from objects
The key principle of Capability-based programming is that features (aka. capabilities) are elevated to a first-class citizen status, allowing for the features to be decoupled from the objects that implement them. This elevation to first-class citizen status allows for objects to be interchanged and/or change their behavior dynamically at runtime without negative consequence to the application using the objects. Objects effectively become simple containers, containing a set of features and attributes that help to distinguish them from other objects.
Developing to features: Developing to to what something does, versus to what something is
The unique identification of features (aka. Capabilities) allows for applications to discover objects within a system or network that expose a desired set of features. Applications that are written to a set of feature, as opposed to a specific object signature, can easily interchange objects without negative consequence. The object and its implementation become irrelevant, provided each feature/Capability represents a common, well-defined behavioral contract, e.g., play, stop, eject, pause, open, close, get temperature. Thereby allowing applications to be developed to what something does, versus to what something is.

Main Menu

See Also

Main Menu