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. 2. Time in force. 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. 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. I agree that an order reference/annotation is absolutely essential.
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. 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. 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.
I was going to ask for a free copy of his software since he kept referring me to it. Seems all of his posts have now been removed.
As far as optimization goes, using reflection doesn't seem like a good idea to me. Why not set the values for the optimization parameters in the XML file that is passed in to create a strategy? This will be also useful to allow the user to manually tweak those values. Instead of having a bunch of overloads to your submit order function, I would recommend just having one function, and passing an Order object to the function. A lot of the members of that object could be optional. If you want to make things easier for strategy developers, you could have a wrapper around the broker interface that provided different functions such as BuyLimit(), BuyAtMarket(), etc. That way each broker wouldn't have to implement all those different methods.
Certainly, it was the intention to provide ability to specify user parameters for a strategy in the XML configuration file. However, I was differentiating between ordinary user parameters and parameters that could be optimized. Perhaps there is no need to differentiate here and put the optimization parameters along with their ranges/values in the configuration file too. If I were to do that, it would impact on how I planned to go about doing the optimization runs so I need to think about it. I probably wasn't clear. The next UML diagram should clear things up though. The buyMarket(),buyLimit() functions are just convenience methods that live only in the SignalGenerator class/interface being overriden. In the background they construct an Order object and submit it to the OrderManager (possibly via filters,position sizing) Essentially, they are only there to provide some sort of resemblence to other software and to make the developer's life just a little bit easier and strategy logic easier to read. They are very thin wrappers consisting of one or two lines of code. There is nothing to stop the developer manually creating Order objects and submitting them to the OrderManager directly as illustrated in the OCAGroup example a couple of posts ago. The broker only has one execution method as per the Provider interface. Thanks for the feedback! Any more insight welcome.
Here is a simplified sequence diagram that I hope will shed some light on the situation. It illustrates the sequence of messages that might occur when a trade event happens and your strategy logic wants place a market order inside an onTrade() handler e.g. Code: onTrade(...) { //...trade decision logic goes here. buyMarket(...); } When broken down like this, it is hopefully starting to look quite straightforward. SimpleMarketDataHandler is simply an implementation of IMarketDataHandler. IBProviderAdapter is an implementation of IBroker and IMarketDataProvider as per the Provider subsystem discussed earlier. I have used a fictional EventDispatcher in this sequence diagram to keep things simple for the moment in lieu of JMS/Spring Events/JMX Notifications etc. In .NET you would probably use Events and Delegates etc. if you were happy with things all being in the same process and slightly tighter coupling. I'm not really familiar with those technologies though so I'm not sure of any shortcomings they might have with respect to concurrency and poorly behaved listeners. I may or may not employ a separate OrderFactory later on and submission to the OrderManager might be delegated back the the enclosing Strategy rather than directly from the SignalGenerator so that filters can be applied . These are all things that will be refined but the basic idea remains as above in the diagram.