Pool

Pools behave like data stores; activities writing to a pool expect data to persist in some way as defined by the pool’s implementation. As with channels, pools may have multiple incarnations.

Channel

Channels behave like pipes; activities write to one end and read from the other. Every channel has an implementation associated with it that defines its behavior; this implementation is shared among multiple incarnations of the channel.

Connection

Connections represent an activity’s access to an IDA. Connections have scope defined as follows:

local — within the context of the defining subsystem.

global — within the context of the global subsystem.

container — within the context of the containing subsystem. If the container is the global subsystem then global and container are equivalent.

argument — the process of binding a connection to its target is delayed until runtime. Subsystems with argument connections expect to find IDA references in their argument vector upon invocation. There is a special notation for argument connections which are labeled to indicate the connection’s name within the subsystem (so it can be referenced) and the reference’s position/index within the subsystem’s argument vector.

device — this IDA is a device reference. Device references resolve in the global context and return 2 channels, a ‘reader’ and a ‘writer’.

Device

Devices are entities that represent access to some process or hardware outside the context of the global subsystem. Devices may be opened which creates an instance of the device under an instance name. Subsequent opens with the same instance name return a reference to the already opened instance. It is therefore possible for subsystems to share device instances; this implies that device instance names should be unique with respect to any particular device. Closing a device will not remove the instance until the last reference is removed. Devices implement 2 channels, a read and a write channel, but may have other behaviors depending upon the implementation.