AlgoTraderAlgoTrader Documentation
AlgoTrader is built on top of the Spring Framework, which uses
BeanFactory
and ApplicationContext to
locate Spring Beans (= AlgoTrader-Services).
The Spring web site provides documentation such as 'The IoC container' as an introduction.
AlgoTrader provides the class
ch.algotrader.ServiceLocator
which will instantiate the adequate BeanFactories &
ApplicationContexts
for a given operational mode depending on
the specified BEAN_REFERENCE_LOCATION.
In Simulation mode the AlgoTrader Server as well as the Strategy run inside the same JVM.
In Live-Trading mode the AlgoTrader Server and strategies can be run in different
JVMs. Through the use of RmiServiceExporters and
RmiProxyFactoryBean, Strategies can call Services from the
AlgoTrader Server. Behind the scenes this is handled transparently through RMI.
Please see Remoting and web services using Spring for further details.
AlgoTrader provides the following Wiring Factories, which are instantiated by the
ServiceLocators:
Table 10.1. Bean Reference Factories
| Wiring Factory | Description |
|---|---|
LocalWiringFactory
| used when no remoting or strategy related functionality is needed
(e.g. HistoricalDataStarter)
|
EmbeddedWiringFactory
| used in Live Trading Mode when running in embedded mode |
ServerWiringFactory
| used in Live Trading Model on the server side |
ClientWiringFactory
| used by the Strategies in Live Trading Mode to connect to Services through RMI |
SimulationWiringFactory
| used in simulation |
AlgoTrader provides the following Wiring Classes and Application Context XML-Files :
Table 10.2. Application Context Files
| ApplicationContext | Description | Examples |
|---|---|---|
CommonWiring
| contains common beans | Configuration, JMX Management, Esper Engine, Event Dispatching, Logging & Web Configuration |
ServerWiring
| contains server bean definitions | ActiveMQ, SSL & REST Controllers |
CoreWiring
| Caching, Configuration, DAOs, Data Source and Transaction Management, Hibernate, Live Cycle Manager, Server Esper Engine, Simulation & InfluxDB | |
AdapterWiring
| contains adapter related beans | market data and trading adapters |
ExternalWiring
| contains external services | market data and trading services |
ClientServicesWiring
| contains all client service beans | SubscriptionService,
MarketDataCache,
LiveCycleManager,
CacheManager &
LookupService
|
EmbeddedJMSWiring
| contains JMS embedded beans | Embedded JMS |
ClientJMSWiring
| contains JMS client beans | Remote JMS |
JMSWiring
| contains JMS server beans | Server JMS |
applicationContext-export-remoteServices.xml
| contains all RmiServiceExporters to make
Services remotely available
| |
applicationContext-import-remoteServices.xml
| contains all RmiProxyFactoryBean to call
remote Services from the Strategies through RMI
| |
applicationContext-client-*.xml
| to be provided by the Strategies | Strategy services, JMS queues |
applicationContext-env.xml
| contains environment specific bean definitions | Mail Settings, Reconciliation Dispositions |
The following table shows which Wiring Classes and
ApplicationContext
is referenced by which Wiring
Factory:
Table 10.3. Application Context References
| ApplicationContext | Local | Embedded | Server | Client | Simulation |
|---|---|---|---|---|---|
CommonWiring
| x | x | x | x | x |
ServerWiring
| x | x | |||
CoreWiring
| x | x | x | x | |
AdapterWiring
| x | x | x | ||
ExternalWiring
| x | x | x | ||
ClientServicesWiring
| x | x | |||
EmbeddedJMSWiring
| |||||
ClientJMSWiring
| x | ||||
JMSWiring
| x | ||||
applicationContext-export-remoteServices.xml
| x | ||||
applicationContext-import-remoteServices.xml
| x | ||||
applicationContext-client-*.xml
| x | x | x | ||
applicationContext-environment.xml
| x | x | x |
For many use cases abstract services are in place which can be extended for different broker interfaces.
For abstract services which have only one active implementation (through
profiles), an alias can be defined for the concrete service (e.g.
iBHistoricalDataService). A typical Spring Bean Alias
definition looks like this:
@Profile("bBHistoricalData")
@Bean(name = {"bBHistoricalDataService", "historicalDataService"})
public HistoricalDataService createBBHistoricalDataService(
final BBAdapter bBAdapter,
final SecurityDao securityDao,
final BarDao barDao) {
return new BBHistoricalDataServiceImpl(bBAdapter, securityDao, barDao);
}
At runtime this service can now be accessed through its alias (e.g.
historicalDataService)
For abstract services which might have more than one active implementation
(through profiles), aliases are not available. In this case the following method can
be used to look up all available concrete services that extend the abstract service
(see OrderService for an example):
ServiceLocator.instance().getServices(OrderExecService.class)
InitializingServiceI
interface represents an
abstract service that requires special initialization after it has been created and
fully wired in the Spring application context. The life-cycle manager automatically
detects such services and calls their
InitializingServiceI#init()
method before proceeding
with initialization of strategy engines and deployment of strategy modules. This
helps ensure that all external interfaces are fully initialized prior to strategy
activation. InitializationPriority annotation can be
used to explicitly mark a service either as a part of the platform core or as a part
of an external broker interface. Core services have higher priority than all other
services and get initialized before all others.