Skip to content
timmolter edited this page Jan 12, 2013 · 20 revisions

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 implementation happens to use the BTC currency due to market demand.

High level overview of architecture

Two approaches were considered: fully self-contained, or extensible. Existing APIs addressing similar problems (such as JDBC for relational databases) demonstrated that the extensible approach is the better choice. This implied that XChange should provide a collection of interfaces that someone will need to implement for their exchange. Clearly, XChange will initially create early versions of these providers, but eventually it is hoped that exchange owners themselves will contribute them. This is actively encouraged.

High level overview of components

The following are the main components that developers will interact with, typically in the order presented below.

ExchangeSpecification

This provides all the configuration for the Exchange including the implementor class name, authentication credentials, API secret keys and so on. Passing this to the ExchangeFactory will result in a suitable configured Exchange to work with.

ExchangeFactory

Is responsible for creating Exchange implementations based on details provided in the ExchangeSpecification.

Exchange

The main point of interaction. Consuming applications will use this to access the various services supported by the exchange by calling one of the supporting getters.

ExchangeService

The entry point to an exchange service (e.g. listing market prices against a particular symbol etc). could be synchronous (blocking) or asynchronous (non-blocking) depending on the requirement.

Message

Standard DTOs for encoding a message to and from the exchange. Treated as immutable.

Where next?

See here for a list of completed and planned milestones