I am interested to find out your roadmap for this project... I think it is a great start, but it's missing too much critical functionality. e.g., limit/stop/moc orders, multi-leg orders, portfolio syncronization and a trade database, failover, etc. Is your plan to develop JSystemTrader into a QuantDeveloper/RightEdge/TS competitor or, more or less, a foundation for building a custom trading platform? I think the latter would be very beneficial, if it provides the event processing/scheduling, simulation/backtesting, and order/broker adapter components. In that case, developers can focus on feed handling, failover, risk management/analytics, GUI, trading strategies, etc.
Simulation and backtesting are already in JSystemTrader. What are the "order/broker adapter components" and "event processing/scheduling"?
Order/Broker adapter... Currently JSystemTrader is hardcoded to IB's API. There should be some extensibility to other brokers, possibly FIX, with the ability to control this at run time. Same goes for data feeds. Job scheduling is needed to control the hours at which to run a trading strategy or other portfolio functions (e.g., close all positions at 3:30 PM on Friday, don't run on market holidays, etc). Quartz is very nice for this. A separate messaging bus would add performance, fault tolerance, fail over, etc. Clearly there are a lot of components to a full ATS, which is why I inquired about a roadmap and your long term plan for the project. Again, it is fantastic that you are sharing your code.
I'd like to keep JSystemTrader as simple, transparent, and easy to maintain as possible. Since I only use IB API, the support for other brokers and data feeds would be an unneccessary weight to carry around. That's already in JSystemTrader.
I don't know how this 'open source' software works.Could someone take your code,hand it on to SourceForge or somewhere similar and ask interested parties to turn it into a universal trading automation tool?I've been to the IB discussion site and it looks like a bit of a mess.Perhaps people at SourceForge or other similar places have greater project experience and could drive it forward more quickly?
If you read the threads at IB you'll notice this suggestion has come up before. Nonlinear has indicated that he would be happy to be a contributor to such a project. However, it requires someone to set up the project and deal with ongoing administration. Sourceforge is just a place for hosting projects. You still need people for governance and code development. When it comes to the crunch there are very few people that will actually contribute to the running and development of this project. Most people just want something for themselves. Lastly, Nonlinear has suggested that the code is feature-complete for his purposes. Therefore there isn't much motivation for him to take it forward.
What you envisage is a completely different proposition. JSystemTrader is a very lightweight and simple system. You are proposing a much more sophisticated and heavy weight architecture. One that is mutually exclusive with JSystemTrader. Perhaps you have some experience in this area. If so, I would like to hear your ideas on the matter. I'm familiar with Quartz both as a developer and an end user (embedded in products like ColdFusion and Jira) and agree it is great and extremely reliable - just what is required for an ATS. As for implementing a message bus i.e. JMS, I'm unclear how you envisage this being implemented and/or why you think it would add performace over and above a simpler multicast event/listener model which I have implemented at the moment. Certainly, it would allow for greater scalability by allowing different components to be located on different servers etc. but I'm not sure of the performance implications when speed is of the essence. As for broker/data feed adapters. I have played around with various configurations to make this plug n play but have yet to come up with a satisfying architecture. I do not want to learn how to use FIX as it seems like a massive undertaking even with implementations like Quickfix already available. However, I don't want to preclude plugging in FIX at a later date for when systems are co-located etc. If you have experience with FIX and retail broker APIs, I would like to hear your views on creating a common interface or appropriate design patterns to cope with different adapters. I'd like to hear your thoughts on the all of the above. Perhaps I will start a new thread for general ATS architecture discussion. PM me or reply here if interested.
What is required to run an ATS is an absolutely reliable and accurate data feed with reasonably low latency. Almost without exception, all of the internet feeds marketed to private investors are not good enough for the job . A pro-quality feed tends to cost about cost you $2-3K per month or more so you need a fair amount of money to trade with in order to be able to afford to do the job properly. All the playing with code is fine but garbage in-garbage out rules in the end.