AlgoTraderAlgoTrader Documentation

Chapter 11. Events and Messaging

11.1. Embedded ActiveMQ message broker
11.2. Embedded Jetty HTTP server
11.3. RESTful interface
11.4. Event Dispatcher
11.5. Event Listeners
11.6. JMS Destinations

AlgoTrader provides a sophisticated event dispatching and messaging sub system. In Simulation Mode as well as Embedded Mode Event Propagation takes places within the JVM. In Distributed Live Trading Mode Event Propagation from the AlgoTrader Server to the strategies (and between strategies) happens via JMS & ActiveMQ

AlgoTrader makes use of an embedded instance of ActiveMQ message broker for message dispatch and delivery. It presently supports three transports by default:

In addition to RMI transport AlgoTrader provides a RESTful interface over HTTP/S. RESTful endpoints serve only a subset of AlgoTrader functionality primarily required for HTML5 front-end. While being a subset it nonetheless represents the core functionality of the platform.

HTTP/HTTPS transport is powered by the embedded Jetty HTTP server and REST endpoints are managed by Spring Web framework.

RESTful endpoints largely expose the same interface as Spring services exposed via RMI. REST controllers must follow RESTful semantic and also use immutable value objects for input / output representation.

AlgoTrader RESTful controllers serve several purposes:

The following RESTful controller provides a list of all accounts available in the system:


@RequestMapping(path = "/account", method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
public List<AccountVO> getAccounts() {
    return lookupService.getAllAccounts().stream()

In this example the @CrossOrigin annotation marks endpoint as permitting cross origin requests. The @RequestMapping annotation defines various aspects of request / response mapping: path attribute defines path element of the request URI, method attribute defines the request method (such as GET, POST, PUT or DELETE), produces attribute defines expected media type of response body. The endpoint method implementation performs conversion of Account Entity objects to AccountVO objects, which are then serialized to JSON data stream by the framework.

For more detailed explanation of REST controllers and Web annotations please refer to Spring documentation.

AlgoTrader uses SWAGGER to document the individual REST endpoints, see:

The EventDispatcher API represents a platform wide communication interface capable of submitting events to multiple Engine instances and event listeners both inside the same JVM as well as to separated JVMs. The EventDispatcher acts as an event bus for the AlgoTrader platform and individual strategies. The following Recipients are available

EventListener represents a generic communication interface to receive events from multiple event producers both in-process and remote. EventListenerRegistry interface represents a registry of event listeners used internally by the AlgoTrader Server process as well as individual strategy processes. One can register listeners for arbitrary event classes, which enables strategies to generate custom events either through Esper statements or in Java code and consume them internally or propagate them to other strategy processes.

The AlgoTrader platform provides a number of event listeners for common event types such as market data events, order events, external session events, life-cycle events, and a few others. Components that implement those event interfaces which are declared in the Spring application context get automatically registered with the platform upon initialization..

Table 11.2. Standard event listener classes

BarEventListener receives BarVO events generated from tick events by individual strategies or fed from an external source
EntityCacheEventListener receives EntityCacheEvictionEventVO generated by the cache manager
FillEventListener receives FillVO events generated by trading interface adapters
GenericEventListener receives GenericEventVO events generated by strategies or by the platform
GenericTickEventListener receives IBGenericTickVO events generated by IB market data interface adapter
LifecycleEventListener receives LifecycleEventVO generated by the life-cycle manager
OrderCompletionEventListener receives OrderCompletionVO events generated by the Server Engine
OrderEventListener receives OrderVO events generated by the order service
OrderStatusEventListener receives OrderStatusVO events generated by trading interface adapters
PositionEventListener receives PositionNutationVO events generated by the transaction service
QueryCacheEventListener receives QueryCacheEvictionEventVO generated by the cache manager
QuoteEventListener receives QuoteVO events (BidVO or AskVO) generated by market data interface adapters or fed from an external source
SessionEventListener receives SessionEventVO generated by market data and trading interface adapters
TickEventListener receives TickVO events generated by market data interface adapters or fed from an external source
TradeEventListener receives TradeVO events generated by market data interface adapters or fed from an external source
TransactionEventListener receives TransactionVO events generated by the transaction service
AccountEventListener receives AccountEventVO events generated by the account service

It is possible to change event listener priority, i.e. define the order in which the listeners are invoked when reacting to an event, by applying the following annotation to the listener method:


@EventHandlerPriority(value = EventHandlerType.EXECUTION, priority = 3)
public void onBar(BarVO bar) {

For EventHandlerType there are three options:

MARKET_DATA_CACHE receives events first, and EXECUTION last.

Events for the same EventHandlerType are prioritized according the to "priority" value

Again EVENT_HIGHEST_PRIORITY will receive events first, and EVENT_LOWEST_PRIORITY last.

Looking at a typical back test there are the following Bar consumers (in ascending order of event delivery):

So it is possible to change the order in which different listeners are invoked:

Events are delivered to strategies via JMS. The following JMS Destinations are defined by the system

Since market data events and generic events are pushed into two topics that are available to all strategies, strategies have to select appropriate messages on their own. This is the job of the SubscriptionService. It will modify the selectors on MessageListenerContainer accordingly and invoke the corresponding methods on the (server-side) MarketDataService (e.g. to request market data for additional securities).