Quote from dcraig:
I think you are being too ambitious.
Thanks for the input and feedback.
I suspect you are not the only one to come to that conclusion based on my high level system requirements!
With that in mind, now is perhaps a good time to adjust expectation levels for those that I hope are following along with this thread. For me, the project and hence this thread is a
long term effort. I'm not expecting to get things done in the space of a few months. I will be taking things
very slowly.
With an adjusted perspective on time frame, perhaps things don't look quite as ambitious.
Another product may come along in the mean time e.g. Frosty's frostengine that makes this thread redundant.
While it is good to keep in mind various design objectives, you (or anybody else) are not likely to get it right the first time around. It might be better to omit some things and resign yourself to some significant redesign/rewrite at some point in the future.
I'm 100% certain I won't get things right first time around. I have already built very poor ATS before and they certainly aren't right! My intention to have
collaboration on ideas is to minimize the mistakes made going forward and to leverage lessons learned from other people if they are willing to share.
I would like to follow an iterative development process.
IMHO candidates for omission might be:
1. Redundancy/fail over. Zero downtime is hard to achieve. Sometimes the most bizarre issues can crop up. Assuming no software faults, is the MTBF of a server grade box with mirrored disks, ECC memory, dual power supplies etc going to be less than that of the broker/data feed provider/comms service provider or even the exchange ? It might sound good but does hw redundancy actually buy you much ?
I would like to produce a solution that is just as comfortable working on a desktop PC with a retail data feed and broker interface as it is working hosted at an exchange or data warehouse on multiple servers with an institutional/exchange feed and execution.
The fail over I was referring to was with respect to application server or JMS.
Depending on your level of knowledge building this can be handled by the third-party components e.g. J2EE servers.
2. Grid computing / clustering. With fast quad core CPUs here now, what are you going to be doing that can't be done on an SMP box ? Running on a single box has got to be easier in terms of software design. (As a curiosity, I read somewhere about a research JVM that distributes threads across a network).
What am I going to be doing that can't be done on an SMP (I assume you mean shared memory multi-proc) box? that would be telling
Again, depending on your level of knowledge I don't forsee it being too difficult to
grid enable an ATS if it is designed with that in mind to begin with. I may be proven wrong.
3. UI - Browser and Swing. One or the other - not both. I can well imagine that both is a lot more than twice the work of just one. My preference would be Swing for performance reasons and it would probably be easier to code.
Actually, I was going to do neither (I hate GUI programming)! My intention of mentioning the client aspect of the ATS was to ensure that the ATS server was built with absolutely no dependency on a GUI thus leaving the door open for any kind of GUI later on as long as a suitable API was exposed.
I'm thinking of situations where the ATS is hosted and you want to connect to it without using terminal services/VNC etc. you could have a web client which was accessible via PDA/cellphone/PC or you could have a thick client which connected over the Internet to your server via web services or some other protocol etc.
I think Eclipse RCP would make a great base for an ATS system but it would be more along the lines of a Rightedge product or even JSystemTrader where the GUI was somewhat integral to the ATS. After much deliberation (yes, I've been planning this for some time), I decided I did not want to pursue that route and prefer a server-based solution instead. Of course, Eclipse RCP could still be used as a thick rich client.
I've also had a play around with Spring Rich which is a neat solution for building Swing-based clients - so that is a possibility later on too. However, it is still a very young project.
I certainly don't want to re-invent the charting wheel. There are plenty of charting packages out there. I even don't want to build a charting component based on JFreeChart or even BIRT charts (part of Eclipse BIRT reporting). This is largely because I hate charts and my algorithms don't really rely on traditional TA indicators etc. However, I'm aware that most people do come from a charting background and progress from custom indicators to alerts to finally ATS based on these things so this may need to be accomodated somehow.
I know what you're thinking...Waaaay to ambitious!
I think that things like GA and ANN are actually relatively easy to incorporate.
Yes they are, I have used both.
Whether they help you make money is another issue.
Thanks for bringing that up. To take another preemptive strike before others chime in, lets make the assumption on this thread that
we already have an edge and successful trading system that we want to automate. Or at least, want to test some ideas out that can't be done otherwise.
At one stage I did write a sort of an ATS platform for backtesting/research and live trading including portfolio level stuff but I've put it on the backburner until I learn more about the market. It needs to be rewritten anyway - hence my opening comments.
Anyway that's just a few rambling thoughts.
Your comments and input are greatly appreciated. I would love to hear about your experiences and any insight you gained from developing your ATS platform as this thread unfolds. Perhaps you can take away some ideas from this thread and we can mutually benefit.
That's the idea anyway!
