Design Notes

General overview

The intention to is allow clients to connect to a wide range of exchanges offering trade opportunities. This is not limited to Bitcoin, although the first exchange happens to use the BTC currency.

High level overview of architecture

There are 2 main approaches: fully self-contained, or extensible. Existing APIs addressing similar problems (such as JDBC for relational databases) prefer the extensible approach. This implies that XChange will provide a collection of interfaces that an upstream provider will implement for their exchange. Clearly, XChange will initially create basic versions of these providers, but eventually it is hoped that exchange owners will contribute them.

To assist in the creation of the underlying exchange provider implementations, XChange should provide a WADL document for each exchange. This can then be used as the basis for creating a suitable client by a language-specific application. Thus, XChange can use it to create exchange providers in Java, whereas another project targeting a different language (such as PHP or Ruby) can use it to generate their own clients.

High level overview of components

Session

The entry point to the overall API Requires various options (authentication, token support etc) so consider SessionOptions parameter object. Has a transport type (asynchronous, synchronous, streaming). Has a lifecycle (start, stop). Runs in own thread pool. Supports multiple services from the exchange through an ExchangeProvider.

ExchangeProvider (interface)

Implementations provide the necessary heavy lifting to allow communication with the exchange type. For example, a MtGoxExchangeProvider would handle all communications with an exchange obeying the MtGox exchange API. The exchange provider is responsible for managing the different exchange services available.

ExchangeService (interface)

The entry point to an exchange service (e.g. listing prices against a particular index etc). Has a lifecycle (start, stop). Sends/receives messages to exchange/listeners.

Message

The DTO for encoding a message to and from the exchange. Probably defined internally as a Map<String,String> for field and resource with appropriate getEntryAsXXX() methods to support different expected internal representations (e.g. JSON, double, text, etc). Treat as immutable. Could consider providing an Enum for standard key lookup, but this may be limiting.