J-Log

Control and Notification Channels Architectural Pattern

Entities in any system – be they software objects, logical constructs or physical entities – communicate with each other to achieve their purpose. In addition to their main topic of conversation – if you will – they often need to communicate information about other things, i.e. they need to communicate meta information. For example they need to initiate and end a conversation and they may need to pause and restart a conversation. Furthermore some other aspect of the system may need to monitor the health of the entities to ensure their availability.

Intent

Define a mechanism to propagate control messages and notifications in a manner that does not interfere with and is not affected by the main channel.

Problem

It is often necessary to issue control requests, or send notifications to or about an entity – be that a local component, a remote component or a communications stream. An obvious way to do this is to implement the control/notification mechanism directly on the component or directly in the datastream protocol. There are several problems with this:

The topic of the control and notifications may be orthogonal to the purpose of the entity or datastream. For example record keeping of the traffic in a datastream is not the purpose of the datastream itself. Controlling the initiation of a session to implement CAC (Connection Admission Conrtol) is not a core concern of the session itself. Writing the values of an object to persistent store is not a core concern of the object being persisted.
The control/notification channel may require a different quality of service. For example the latency requirement of a video stream control channel is different than that of the video stream itself.
The control/notification channel may need to be unaffected by the functionality of the entity or stream. For example recording that a process has crashed can't be done by the process. Aborting a locked datastream can't be done by inserting a message into the datastream.

Solution

Implement separate control/notification channels. In general channelization can exhibit the following characteristics:

Independence
Multiplicity
Layering
Abstraction
Aggregation
Re-purposing

Independence is provided by implementing a separate channel from that used for the main interaction – be it a separate communications channel for a datastream or a separate interface for an object. It allows the requirements of the channel to be fully addressed and ensures that the main channel is not compromised to meet those requirements.

In general the independence of channels can only be guaranteed to a certain level. For example using a separate control channel for a communications protocol may require separate threads, separate queues, separate sockets, separate NICs, separate networks and separate routers depending on the QoS/SLA required.

Multiplicity provides channels targeted at a specific purpose. So for example you may have channels for:

Logging
Record keeping
Control
Querying

The advantage of multiple channels is that it enforces a separation of concerns – which is widely accepted to be good design practice – and helps to ensure that the system can be adapted to future requirements by adding more channels.

Layering occurs when one person's control channel is another person's data channel. This is especially true where commands and notifications are re-purposed. For example RADIUS messages are a separate channel from the session they are reporting on but can easily be re-purposed into session start and stop notifications.

Abstraction is used to define a consistent vocabulary onto which external commands and notifications can be mapped – allowing a system to be developed against the abstract vocabulary rather than a specific realization of that vocabulary by an external (or internal) entity.

Aggregation and Re-purposing occurs when existing command/notification channels are mapped to other channels and other vocabularies. Such re-purposing and aggregation may require the maintenance of a state machine.

Applicability

In a distributed system a signaling protocol should be used to locate remote objects that is separate from the data channel used to communicate between those objects.

Data channel back-pressure can be more readily signaled through a separate control channel than through the data channel itself which, by definition, will be congested at the time.

Billing records may use a separate channel from the main data channel or from even from the session signaling channel – for example we may aggregate, translate and enhance RADIUS accounting records for a customer's billing server.

A system management application needs to be able to determine the health of the components in the system and control their behavior. It does this using communication channels that are orthogonal to any channel use by the system for its normal functions.

Known Uses