order flow control java multi threading

[nikol]

Hi. I have lost my esteem to put this forward. Right now developing and testing trade interface for python based system.



FinSecurity holds info about traded instrument

IBLInk is extension of EWrapper (provided by IB)

--- it holds Main(), feed (tickPrice/tickSize) and trade (orderStatus, execDetails, cancel etc)



When tick arrives into tickPrice/tickSize:

--- select quoted FinSecurity and fire MacroStrategies registered with this FinSec

--- store current info into DataFeed object which keeps all current info about the Market. I use it for example to identify Arbitrage.



Within MacroStrategy you calculate all your signals. When trade is triggered you send request to MicroStrategy.



Within MicroStrategy you can model dynamics of monitored price and execute in optimal way.



Arbitrage is an object which simplifies communication between FinSecurities within Strategy.



All order updates are captured via IBLink and used to update Position of FinSecurity. Position is shared, therefore, lock/sync mechanism has to be implemented.



When you trigger the signal you have to compare your target Position with Position you have + total volume of orders in the system, otherwise at some point you get infinite generation of trades.



GUI/Swing required info from objects, therefore, I guess I created total mess by mixing dataflows for Strategy/Trading and for GUI.





As I see, my architecture is over-complicated. I do it differently now. For example, to implement market making strategy I had to create two instruments A_BID and A_ASK, which interacted via Arbitrage. This made things even more complex. Now, I use distribution based approach, where I set Target order-distributions (by model), and execute only differential order distribution between Target and Actual (on the market).





Ask more questions, I will answer, when have a time.

[bullero]

Your approach sounds quite complicated. Here is a crude description of how I have approached this type of stuff previously, maybe it helps:



1. OrderBook class (for example market-by-price style):

This is just a container class for std::map(int,int) (price and size) that has couple of methods to keep the book organized. So you could create "update", "insert" and "delete" methods to manage the price and size information based on your data feed. Depending on your hardware implementation you maybe want to make this class thread safe.



2. Create general template classes for observer/subject design pattern for later use. You can find various implementations from Google or some programming design pattern books.



3. Create template class OrderBookUpdater by inheriting the "subject" class interface that you created in step 2. The purpose of this class is to take any type of OrderBook (for example, market-by-price or market-by-order style) as an input, refresh it and notify "observers" when the state of the order book is modified. So this class subscribes to real-time feed socket, filters out specific ticker or symbol, parses the FIX message into meaningful bits of information, updates the OrderBook state and notifies all "observers". When a notification is made copy of the current state of the orderbook is passed to the observer.



4. Create template class OrderBookObserver by inheriting the "observer" class interface that you created in step 2. The purpose of this class is to receive notification every time the OrderBookUpdater makes any modification to the OrderBook.



5. For your strategy class you maybe want to create general interface class StrategyBase which provides basic methods common to all different types of strategies. For example, every strategy needs to be able to send orders to trading server, check currently outstanding orders and positions, handle fill messages etc. So this base class takes care all of that stuff.



6. Create a concrete implementation of a strategy by inheriting StrategyBase and OrderBookObserver.

[nikol]

I confirm, my old implementation is complicated, so I abandoned it by sharing to the world.



Today I do it with a friend (with heavy programming background at the bank) and we do closer to what you describe. At least Arbitrage is removed from the picture:



Instrument Feed (as many as we requested) message is passed to all strategies registered within Instrument. Not all Instruments are traded.

Strategy ( = your StrategyBase) implements base methods

for example, MarketMaking inherits Strategy and is registered with Instrument (when Instrument's quote is coming it calls all registered strategies)

- monitors market and indicators

- monitors current positions via Portfolio/positions

- monitors current outstanding orders via ExecutorRealtime

- triggers trading via Executor (I have several)

ExecutorRealtime (=OrderBookUpdater) manages all orders related to the Instrument

- when app receives info that the order is filled, it is booked into 2 Positions (base and asset). It does not notify anyone, but allows reading its state.

ExecutorBackTest updates directly those 2 Positions. No orders are involved. Plan to make some simulation of reality (delay, market orders arrival).



In this way we can do multiple exchanges, instruments (securities), strategies in one app. Executor will be more complicated...

Same framework is used for BackTest. We store Feed online into our DB and then play it back by feeding Feed (then all is executed in the same way)



Target strategies: market-making, triangle and momentum (even using interval based techniques).



Do I understand correctly, that Observer also helps to separate Feed layer from the Strategy?

Or you do it only for OrderBook? Why do you need notification if updates of Position & Orders are done simultaneously?

[bullero]

So the OrderBookUpdater subscribes to feed socket which delivers all order book updates. If message contains a message for some particular security, "ESZ18" for example, then it parses the message and updates the state of the book. Then, the updater tells the strategy that the state of the book has changed. The strategy does the necessary computations etc.