Quote from dcraig:
Tricky business order management, I suspect. Other issues to consider:
1. Order routing where there is a choice of exchanges or even choice of brokers.
Agree. Part of this goes back to the question of instrument normalization that I raised earlier on in the thread.
Essentially, the solution is to have an equivalent to Fatrat's Product Manager/ NeoTickers Symbol Manager.
What you do is set up an Instrument definition which contains information such as Symbol, Currency, Exchange perhaps. I was thinking of modelling the fields on IB's Contract object and/or the FIX Instrument block.
Then, you have
mappings that are able to translate that Symbol to Provider specific Symbols and definitions if neccessary.
It is the job of the provider adapter to look up the mapping from the Instrument registry when it is passed the normalized Instrument object/Symbol.
So for IB you would specify SMART or the specific exchange you wanted to use for that Instrument. Of course, this means there is only the choice of using one exchange per symbol and it is basically set at design time.
So a strategy which needed to trade the same symbol but at different exchanges would only be supported by first retrieving the Instrument from the Instrument Registry (or unless it was was set or passed in to the method) and then explicitly set the exchange before passing it to the order management method thus:
Code:
onBar(Instrument i, Bar b) {
i.setExchange("SMART");
buyMarket(i,100,"Smart routing please");
}
As for dealing with choices of brokers, that's an interesting one. I must admit I only considered the scenario where a Strategy would only use a single broker for execution (as defined in the configuration file). In the Strategy's startup/initialization, it connects to the specified market data provider and broker.
I suppose some sophisticated ATS would want to execute via multiple brokers and/or accounts from the
same strategy? If you could provide a use case for this, that would be great.
Of course, the current architecture already facilitates different strategies using different brokers.
Yes, I missed that one. Yet another optional argument. I'm going to have a look at varargs in more detail.
3. One cancel all order groups. On the assumption that your broker is likely to be an order of magnitude more reliable than an internet connected ATS, if positions are bracketed by a stop and a limit then a OCA order group is preferable to having the ATS cancel the other order when one is filled.
Agree. Utilizing the broker's OCA mechanism is preferable where possible. I was looking at how creating an OCA group and submitting it could be made easy from an API level. The simplest solution is to have
yet another optional argument which specified the OCA group identifier for separate orders.
As stated earlier the buyMarket,buyLimit methods are essentially convenience methods that not only create Order objects but also submit them to the OrderManager (or to Order Filters before getting to the OrderManager).
There's no reason to dissallow the end-user from creating Order objects manually and submitting them to the OrderManager themselves e.g.
Code:
myOCAGroup = new OCAGroup();
myOCAGroup.addOrder(new Order(OrderType.STOP,xxx,"Stop Loss"));
myOCAGroup.addOrder(new Order(OrderType.LIMIT,xxx,"Profit Target"));
//we have direct access to the OrderManager through the
//construction of the base class
orderManager.submitOCAGroup(myOCAGroup);
What do you think? The OCAGroup object deals with assigning the group identifier to the Order objects it is composed of.
4. What is a reasonable common denominator of order functionality that the ATS should expect from a broker interface ? This might be a tough one to answer.
Agree, I have no idea what is reasonable in this respect until I have a look at some other broker interfaces. The suggestion you made earlier about capabilities interrogation of the provider interface seems to be one way to deal with it.
As for broker's that don't support OCA natively, the functionality could possibly be built into the OrderManager so when OCA groups are submitted to it, it first finds out if it is supported by the broker (via interrogation), if not, it maintains the responsibility for the OCA group, cancelling the respective order at the correct time which it should be able to do with little effort as it receives execution reports.
