AlgoTraderAlgoTrader Documentation

Chapter 10. Spring Services

10.1. Wiring Factories
10.2. Application Context
10.3. Abstract Services
10.4. Service initialization order

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:

AlgoTrader provides the following Wiring Classes and Application Context XML-Files :

The following table shows which Wiring Classes and ApplicationContext is referenced by which Wiring Factory:

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:


@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):


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.