AlgoTraderAlgoTrader Documentation

Chapter 26. Spring Services

26.1. BeanRefFactories
26.2. ApplicationContext
26.3. Spring Profiles
26.4. Abstract Services
26.5. Service initilization order

AlgoTrader is built on top of the Spring Framework, which uses BeanFactory and ApplicationContext to locate Spring Beans (= AlgoTrader-Services).

The SpringSource 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 JVM's. Through the use of RmiServiceExporters and RmiProxyFactoryBean, Strategies can call Services from the AlgoTrader Server. Behind the scenes this is done transparently through RMI.

Please see Remoting and web services using Spring for further details.

AlgoTrader provides the following beanRefFactory XML-Files, which are instantiated by the ServiceLocators:


AlgoTrader provides the following ApplicationContext XML-Files :


The following table shows which ApplicationContext is referenced by which BeanRefFactory:


In addition to BeanRefFactories which define the different operational modes there are Spring Profiles which can be enabled on top for different Use Cases or left disabled if they are not needed (e.g. ReferenceDataService in Live-Trading-Mode).

General Profiles

DataSources

Bloomberg

Currenex

DukasCopy

Fortex

FXCM

InteractiveBrokers

JP Morgan

LMAX

RealTick

Trading Technologies

All other services not mentioned above are active in all profiles.

To enable a Profile on start-up, the following vm argument has to be used:

-Dspring.profiles.active=iBMarketData,iBNative

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.