A channel is a variation on the standard subscription model that enables private, one-to-one bi-directional communication between a single client and the Caplin Platform.

Channels are used for exchanging messages between clients and an integration adapter; for clients to issue commands to the Caplin Platform; and for integration adapters to send different data to each client.

Channels contrasted with standard subscriptions

The implementation of a channel is best described in contrast to the implementation of a standard subscription.

Standard subscription

In the standard publish and subscribe model, clients subscribe to a subject and are served by a single object in Liberator. Liberator populates the object from a single subscription to a component deeper in the Caplin stack (ultimately from the integration layer).

This architecture has the following qualities:

  • All clients receive the same data. A subject cannot contain separate values for each client.

  • Bi-directional messaging is not possible. Theoretically, clients could contribute (publish) to the shared object, but they would overwrite each other’s contributions. In any case, any message sent in reply from the integration layer would be broadcast to all clients, and not just the original sender of the message.

The example below shows a simple architecture for supplying pricing data.

channels standard pricing

Channel subscription

In the channel model, clients still subscribe to a single subject but internally that subject is mapped to a private object for each client. The private objects are differentiated by the presence of the clients' usernames or session names in the objects' subjects. The mapping process is invisible to clients, and clients are not aware of the private objects.

This architecture has the following qualities:

  • A subject hosted by Liberator can store a different value for each client

  • The integration adapter now receives as many subscriptions as there are subscribing clients

  • Because the username is embedded in the subject of each private object, the integration adapter can identify the owner of each subject.

  • Bi-directional messaging is possible. Because each client now has its own private object, clients will not overwrite each other’s contributions to the subject. Likewise, messages sent in reply from the integration adapter will be served to a single client only; a private, one-to-one broadcast.

The example below shows how a single subject, '/PRIVATE/BLOTTER', can, through object mapping, be used to serve different data to each client.

channels blotter 2

Channel examples

Channels can be categorised according to the direction of data flow:

Direction Example

Differentiate between clients when serving data

Client←Caplin Platform

Blotter channels

Send commands to the Caplin Platform

Client→Caplin Platform

Control channels

Exchange messages

Client↔Caplin Platform

Trade channel

Blotter channels

A blotter channel is an example use of a channel by an integration adapter to send different data to each client. Each client subscribes to the same subject, '/PRIVATE/BLOTTER', but receives data that pertains to their trading activity alone.

channels blotter 2

Control channels

The watchlist control channel is an example use of a channel to send commands to the Caplin Platform, in this case Transformer’s Watchlist Service.

The Watchlist Service on Transformer monitors the private control objects for commands to create, rename and destroy watchlists. Watchlists are private to each user; thus, it is important that the Watchlist Service distinguish between the commands of one user and the commands of another.

channels watchlist control

Messaging channels

A trade channel is an example use of a channel by a client and adapter to exchange messages. Both ends of the channel publish and subscribe to the channel.

channels trading

Channels and load-balancing

For some channels to work correctly in a load-balanced environment you must selectively enable the load-balancer’s source affinity option.

For more on source affinity, see:

Channel APIs

Blotter channels

Integration APIs for serving blotter data from an Integration Adapter.

API Version Details

Blotter Integration API for Java


A lightweight API for managing blotters.

See package com.caplin.datasource.blotter, distributed as part of the Caplin Integration Suite.

FX Integration API for Java


The FX Integration API is a high-level API that includes functionality to serve data to the standard set of blotters in FX Suite products. It uses the Blotter Integration API internally.

See parent package com.caplin.motif.fx.blotter in the API documentation for the FX Integration API.

Messaging channels

APIs for managing the exchange of messages over a channel.

API Version Details

StreamLink for JavaScript


Client-side API for exchanging messages with the Caplin Platform

StreamLink for Java


Client-side API for exchanging messages with the Caplin Platform

StreamLink for Android


Client-side API for exchanging messages with the Caplin Platform

StreamLink for .NET


Client-side API for exchanging messages with the Caplin Platform

DataSource for Java


Integration API for exchanging messages with StreamLink clients. Distributed with the Caplin Integration Suite for Java.

DataSource for .NET


Integration API for exchaning messages with StreamLink clients.

See package Caplin.DataSource.Channel in DataSource for .NET API documentation

See also: