Thanks for that. I'm familiar with some of the concepts or related technologies of ESP such as SOA and EDA etc. Not sure if you reviewed my earlier post on dealing with events. I'm opting to use a messaging solution as the backbone for relaying events in an ESB fashion. This affords easy implementation of SOA and EDA. In the Java world at least there are some great open source tools such as: Mule http://mule.mulesource.org/wiki/display/MULE/ and various JMS providers e.g. http://www.activemq.org/site/home.html Monitoring tools: http://www.hermesjms.com/confluence/display/HJMS/Home etc. Some of these components facilitate clustering, parallel processing, concurrency, event databases etc.
So you mean simplistically: the ATS algorithm/logic/code working on CEP, being able to work on events in parallel, concurrently and coming to trading decisions via certain rules in combination with those events. Whatever gives you an trading edge I guess! I'll certainly review this area in more detail. The ATS framework I have in mind will provide most of the infrastructure (as detailed) in order to achieve this if an ATS required those capabilities e.g. the ATS logic could leverage the scheduler to for timer-based events, the various topics and queues to receive external events such as market data, execution report events, portfolio events, and in combination with a rules engine or programmed logic, trading decisions events could be raised and/or sent to the order queue, all of this happening concurrently etc. Certainly, market data or onBar() as you put it, is only one stream of events that an ATS might be interested in. Of course, I could be missing the entire point as CEP and ESP are barely more than acronyms to me at this point. -------------------------- Speaking of rules engines, Java aficionado's might be interested in: JBoss' Rules :http://labs.jboss.com/portal/jbossrules/?prjlist=false It used to be Drools before JBoss took it over.
The guys at Codehaus have done it again with an open source 100% Java CEP ESP component: http://esper.codehaus.org/index.html This case study is particularly relevant: http://esper.codehaus.org/evaluating/tutorial/feedmonitor_casestudy.html Not as feature/functionality rich as some commercial products but something to look at for Java devs. OK, I've just realized this is getting a little off topic....back to earlier discussions.
FYI Java developers: I'm leaning towards using Spring with Spring Remoting to access Spring managed objects in disparate Spring containers (inter-JVM or inter-server etc.) rather than using an EJB3 container like JBoss. Anyone see flaws/drawbacks of this approach? It should keep things fairly lightweight and there is support for message driven POJOs in Spring natively (v. 2.0) or via Jencks: http://jencks.org/ Anyone with experience in this area chime in now!
Provider Interfaces etc. Comments on naming/naming conventions or other more important suggestions please:
I have obviously omitted an interface for Historical Data providers in the UML above. Whilst I'm working away on the specifics of the provider subsystem, I'd like to move on to some higher level stuff for discussion.
Assuming the provider subsystem deals with input/output with the external world I'd like now to focus on what is done with the incoming market data and what is generated from it i.e. the real black box part of an ATS and how it might be structured for re-use, backtesting, optimization etc. The concept I have in mind is to have a single Strategy Container. Into this container can be loaded one or more Strategies whereby each strategy can: - Define where it's getting it's market data from. - Define which broker it will use. - Be started and stopped independently. - Be backtested and optimized independently. In other words, you can have multiple strategies all running at the same time, some being backtested whilst others are being run live. Furthermore, strategies can share or use different market data providers and brokerage providers. The cost of this flexibility is probably some degree of complexity but we shall see if it is too burdensome or not in the following discussions.
I envisage desribing the configuration of a strategy declaritively perhaps in an XML file. This has a few benefits; the main one being that black box strategies can be distributed but still allow parameters to be easily adjusted by the end user via the metadata for the strategy in the XML file. The configuration of a Strategy object may end up being quite complex so a static factory method (getInstance()) is probably warranted? Any other ideas on how best to handle this and keep it clean, much appreciated. Here is a sequence diagram outlining the basic process: Any UML experts please let me know where I've misused/abused notations etc. Currently, Strategy Container is just a thin wrapper around a collection (Hashtable) of Strategy instances but this may be extended further in future.