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
- Channel examples
- Channels and load-balancing
- Channel APIs
The implementation of a channel is best described in contrast to the implementation of a 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.
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 can be categorised according to the direction of data flow:
|Serving data to StreamLink clients||Client <- Caplin Platform||Blotter channels|
|Receiving data from StreamLink clients||Client -> Caplin Platform||Control channels|
|Exchanging (serving and receiving) data with StreamLink clients||Client <-> Caplin Platform||Trade channel|
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.
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.
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.
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:
- Data services : Source affinity for an overview
- Load balance adapters using source affinity for detailed configuration instructions and examples
Integration APIs for serving blotter data from an Integration Adapter.
|Blotter Integration API for Java||6.2.0+||
A lightweight API for managing blotters. See package com.caplin.datasource.blotter.
|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.
APIs for managing the exchange of messages over a channel.
|StreamLink for Java||6.2.5+|
|StreamLink for Android||6.2.5+|
|StreamLink for .NET||6.2.5+|
|DataSource for Java||6.0.0+||
Integration API for exchanging messages with StreamLink clients. See DataSource for Java.
|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