We’re almost done with this series, and we’ve covered some important and profound concepts. Let’s take a quick look at what we’ve learned so far. We’ll break it down into two parts: form and flow. Below is a graph that includes the main concepts of the Substrates API with their compositional and constructional relationship with other concepts labeled.

The Cortex is the bootstrap class into the Substrates runtime. From there we can create one or more Circuits that represent the resource scaling management strategy – the more Circuits, the more Queues, and parallelism.

A Circuit allows us to create one or more Conduits, where a Conduit is a named set of Channels of the same emittance data type – a Conduit is limited to a single communication content type. We can have many Conduits of the same type.

The Circuit is only playing the role of a factory in creating a Conduit and providing it access to the underlying queued pipeline. It doesn’t manage the lifecycle of the Conduits, though it does control the work Queue employed.

Please note that a Clock is a variant of a Conduit where the ability to create and access Channels isn’t exposed directly.

A Conduit has a Source that clients can use to register one or more Subscribers, each having a Subscription that’s managed by the Source but also allowing for cancellation by a client. Subscribers don’t have access to Channels instead they’re provided the Subject of Channel and the Registrar (not depicted here) associated with that Subject. Using the Registrar, a Subscriber can register one or more Pipes with each Subject, though in practice it’s usually one.

The Subscription is at the Source level, whereas the Subscriber registers outbound Pipes at the Subject level.

A Conduit creates multiple named Channels, which can be decorated by a Composer (not depicted here). There’s only one Channel per Name supplied in each call to a Conduit’s get method. Channels are thus managed within a container.

Each Channel has a Pipe that can be wrapped by a percept, created by a Composer, to emit data into a Circuit’s Queue.

Some more advanced types like Path, Sift, and Sink have been omitted for brevity, but that covers the essentials.

Now, let’s delve into the communication aspects, specifically the flow from a Percepts’ Pipe to a Subscribers’ Pipe.

When a client calls on a percept, an instrument, there’s either some data collected from the environment and/or transformation of the call arguments before a value is published to its Pipe, an inlet, using the emit method.

The next stage is optional where a Path, an assembly of pipeline operations, is applied before the work is enqueued with a Circuit’s Queue for delivery to consumers. After this happens, another sequence of pipeline operations may be applied before the value emitted is dispatched to one or more Pipes added by one or more Subscribers. These pipes are labeled as outlets. Outlets represent an extension point for clients and their frameworks such as a data sink.

The above is a simplified conceptual model a developer should employ when working with Substrates. Service providers of the Substrates interfaces are free to implement it in whatever manner they see fit for the environment of execution, including language and runtime. In the final post in this series, we’ll discuss the current reference implementation used to test the design for performance, correctness, and robustness.