Project Description

A RESTful web service that can calculate the position of multiple FX trading accounts at any point in time given the associated trades and transactions.

About the project

The name of the project comes from the Greek word θέσις which literally means position (also proposition, under a different context mostly used in academia). The purpose of this project is to investigate the simplest and most flexible architecture to solve a problem like position tracking and evaluation using a combination of REST services and web sockets.

NOTE: This is NOT a complete product. It serves as a working example of a particular architecture and is a work in progress.

REST and persistent connections

The Representative State Transfer (REST) architecture offers a number of advantages
  • It provides a remote API for a number of different clients both web and native, easily accessible even from third party applications like excel.
  • The communication between client and server is stateless which makes the service much easier to be tested in isolation.
  • It scales really well since the service can be located in multiple servers behind load balancing infrastructure.
However REST is a pull architecture meaning that the clients have to periodically request (poll) the service in order to receive the current state of a position. This architecture is preferable for scenarios where we want to do some analysis on historical data. With a RESTful service we can pull the data we need on demand.

The opposite approach would be a push architecture in which the server would be able to update the clients every time there is a change to a position. This architecture is preferable for scenarios where we want to monitor the current position as it changes. The server needs to maintain a persistent connection so that it can update our client and push the relevant data only when the situation changes (position moves, prices update etc)

A solution to the polling problem would be to maintain a persistent connection between client and server and update the clients only when a new event occurs. The advantages are that:
  • Client doesn't have to wait for the next poll interval to be updated resulting to faster updates.
  • There is no unnecessary communication between client and server when there is no actual change (less traffic and load).
Fortunately there are techniques that allow us to achieve that kind of behaviour over HTTP without having to resort to raw sockets.

Implementing both

In order to solve our problem we would like to be able to provide both a pull and a push service instead of trying to compromise with one or the other. To achieve that OpenThesis is built on top of a number of open source projects that have been chosen because of their simplicity and performance.

Service Stack is a framework that simplifies the creation of fast RESTful services without getting in the way. It comes with a suite of high performance tools from text serialization to ORMs. It is used to create the RESTful part of our service.

SignalR provides an abstraction of bi-directional communication between a client and a server over HTTP. The plan is to use SignalR to broadcast live updates to clients of OpenThesis.

Last edited Mar 11, 2013 at 3:24 PM by meldim, version 15