In this post, we introduce the concept of Container in the Substrates API. A Container is a collection of Conduits of the same emittance data type. With the concept of Container, we introduce a new element in the Subject hierarchy. So instead of a Conduit being parented by a Circuit, it can now also be parented by a Container which is then parented by a Circuit.

Before Containers, we mapped an active processing or situational concept in a domain to a Circuit, where a Conduit would represent an entity concept and a Channel (and Percept) some behavior or mutable state of the entity.

With the Container interface, we can delegate management of a collection of Conduits to the Substrates runtime as opposed to the clients of Substrates as in our last post where we employed a map to track Conduits representing parties.

Here is the definition of a Container in the Substrates API.

A Container is a Pool of Conduits which are Pools for percepts.

The Container doesn’t expose the Conduits themselves, but instead, their Pools, which allows for implementation optimizations and ensures the Container has complete management of the Resources it provisions and manages.

The Container interface extends the Component interface, which extends the Context interface. This means a Container is a Source, but not a Source of the emittances of the underlying Conduits but the creation of Conduit’s Source instance.

We can then use the subscribe method in the Source interface to subscribe to each of the Conduits. We subscribe to the Container’s Source, and upon receiving a callback that provides access to a Conduit’s Source, we subscribe to the Channel.

An example will help cement our understanding of the Container and its usage. Let’s tackle the problem of capturing orders coming into an exchange where there are multiple stocks available to buy and sell.

We’ll first create a Circuit. Then, we’ll create a Container that creates on-demand Conduits for each stock lookup.

Now we’ll subscribe to the Container’s Source. The stock is the Subject of the Conduit, and the type is the Subject of the Channel. The variable named orders is the Source of the Conduit, and the order variable is the emitted value.

We now look up a stock named Pipe and emit an Order. The first get call below gives us access to the Pool for a stock-mapped Conduit and the second get call gives us access to the order’s type Pipe.

The following will be printed by our subscriber above.

If we were to print out the Subject of an order type it would be like this: