Channels

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.

Contents:

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.

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.


Channel examples

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

  Direction Example
Serving data to StreamLink clients ClientCaplin Platform Blotter channels
Receiving data from StreamLink clients ClientCaplin Platform Control channels
Exchanging (serving and receiving) data with StreamLink clients ClientCaplin 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.

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.

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 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 channel APIs

Integration APIs for serving blotter data from an Integration Adapter.

  API Version Details
Blotter Integration API for Java 6.2.0+

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 2.3.3+

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 channel APIs

APIs for managing the exchange of messages over a channel.

  API Version Details
StreamLink for JavaScript 6.2.5+

Client-side API for exchanging messages with the Caplin Platform

See caplin.streamlink.Channel and caplin.streamlink.ChannelListener

StreamLink for Java 6.2.5+

Client-side API for exchanging messages with the Caplin Platform

See com.caplin.streamlink.Channel and com.caplin.streamlink.ChannelListener

StreamLink for Android 6.2.5+

Client-side API for exchanging messages with the Caplin Platform

See com.caplin.streamlink.Channel and com.caplin.streamlink.ChannelListener

StreamLink for .NET 6.2.5+

Client-side API for exchanging messages with the Caplin Platform

See Caplin.StreamLink.IChannel and Caplin.StreamLink.IChannelListener

DataSource for Java 6.0.0+

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

See package com.caplin.datasource.channel

DataSource for .NET 6.0.2+

Integration API for exchanging messages with StreamLink clients.

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


See also: