Architectural overview

The Caplin’s Trading API provides all the data structures and services required to connect the trading components in your trading application, such as trade tickets, to your backend trading system. When integrated with your front end this library allows you to model your own trade workflows, create trades which communicate with the server, and follow their execution to update your components accordingly.

A Trade Model represents a type of trade, for example a Request for Quote (RFQ) or Executable Streaming Price (ESP). Trade models consist of a number of states and transitions, and are defined by XML configuration. The trade model controls the flow of a trade by defining all the possible states the trade can be in, and the messages that cause transitions from one state to another. The diagram below depicts a typical ESP trade model:

Each Trade object created is associated with one trade model, hence determining what messages can be passed between that trade and the server. A trade can contain one or more trade legs each representing the different phases of a trade transaction, such as are used for an FX Swap trade.

Trade Factories are responsible for the creation of trades and for restoring existing trades to their last known executing state when a user logs in to the trading application. Each trade factory implementation can be adapted to creating different trade objects with the required fields. A new trade can be created anywhere within the application via a central Trade Service which delegates the creation of the trade to the appropriate factory.

A trade communicates with the server via a Trade Message Service which handles communication for all trades and routes the server’s messages to the appropriate trade objects. This architecture allows a separation of the client to server communication protocol from the trade object and is also able to notify active trades when trading capability is unavailable.