TraderMojo, Have you used the OpenTick feed recently ? I'm subscribed to it for stocks (how could you not at $4 per month ?), but I put it on the backburner because it seemed really unreliable. TCP disconnects and the Java API code was apparently spinning. It seems there are a number of bugs in the Java API and are they are basically waiting for the users to fix them.
OK, here is some trivialized psuedo-code for what I have in mind. It ignores a lot of details: Code: IMarketDataHandler mdh = new DebugMarketDataHandler(); //Alternatively... //IMarketDataHandler mdh = new JMSMarketDataHandler(); IMarketDataProvider mdp = new IBAdaptor(mdh); //Alternatively... //IMarketDataProvider mdp = new OpenTickAdaptor(mdh) mdp.connect(); mdp.subscribe(...); mdp.unsubscribe(...); mdp.disconnect(); Obviously this is very simplistic. However, I hope the concept and essence is clear: 1) An interface IMarketDataHandler which hypothetically has methods like onQuote(), onTrade(), onError() etc. It is the responsibility of the adaptor to translate their native callback handlers into the normalized methods of the IMarketDataHandler interface. Using an interface for handlers allows people to provide different implementations e.g. a debug handler that simply dumps the information. A JMS producer which posts the data to various topics. The handler could even be the entry point to someone's custom ATS. 2) An interface IMarketDataProvider which hypothetically has methods like connect(), subscribe() etc. It is the responsibility of the adaptor to translate these methods into the relevant native calls. Now, there are a multitude of problems with this idealized arrangement but I don't see the problems as being insurmountable. The immediate problems I have are the following: 1) Dealing with connection/authentication parameters. For example, the IB adaptor connects to a port. The OpenTick adaptor connects to a server(s) with authentication parameters. Obviously some kind of factory seems warranted here so any ideas on the matter much appreciated. 2) Dealing with unsupported functionality or dealing with lowest common denominator functionality. I'm looking for ideas on how best to deal with the different capabilities of different providers. Perhaps throwing unsupported runtime exceptions for those providers with less capabilities etc. Again, ideas please! 3) Dealing with errors. Connection errors etc. My thoughts are give the responsibility of the adaptor to package native errors into a normalized format which then get's propogated. The question then becomes, propogate the error via exception mechanisms or via IMarketDataHandler interface onError() method and leave it to the implementation of the handler to decide how to deal with the error. 4) Subscribing, unsubscribing etc. normalization of instrument/symbols etc. If normalized, normalized to what? Is the QuantDeveloper approach of being FIX-oriented worth pursuing? Should it be left to the adaptor to convert the normalized instrument/symbol/contract to a native format? etc. Thoughts/ideas on this matter please! 5) The most annoying problem for me has been to deal with the fact that IB and others are both data providers and broker interfaces. Therefore, one would want to re-use the existing connection when it comes to instantiating a broker interface. However, things can get more complicated than that: You may want to have market data from one source and execute via another. You may have a system that executes some trades via TWS on one port, and another system that executes some trades via TWS on another port or even another IP address etc. So lots of things to think about. I'm really trying to keep posts as short as possible without omitting pertinent information but it's a little tricky. I've just downloaded StarUML to see what it's like and hopefully communicate ideas via diagrams in future. I'll have to get back up to speed on UML. It's all been a very long time...!
Send me a PM, and I'll provide you with free-hosting and a unix shell to the account. The only condition on the free-hosting is that if I get a traffic spike because of your work, you'll help me pay for the bandwidth. (If we're getting traffic spikes, we might as well make money off of them ). You can post here as well as to a blog of sorts. I have a deal I'm not making effective use of, and I wouldn't mind starting a collection of information regarding trading strategy implementations. My self-interest in providing you with hosting? I want greater transparency into your project, documentation, and source. I want your project to continue to completion, as well. I'll be mirroring your own work with my implementation. If you keep coding, it'll keep me motivated.
Just define a Broker and a separate Feed Interface. Implement both in a single Class for InteractiveBrokers (for example), or just implement Feed in eg OpenTick Class. Thats how I do it. I don't see any problems. Multiple sessions to same broker ? Use arguments to Broker.connect (..). Maybe varargs (though I have never used it in Java).
Service interruptions (disconnect etc) should be propagated as events, not as exceptions. Think of the apadpter as providing a service like one of the layers of the ISO 7 layer model. In this model disconnections are reported as events to the next higher layer where they are handler explicitly in the specified FSM. They have the same logical status as any other event passed over the service boundary.
Possibly capability negotiation. Higher layer asks adapter for a set of capabilities. Adapter tells it what it can provide. Higher layer modifies it's behavior accordingly or gives up if capabilities are insufficient.
I have used OpenTick recently but mostly for historical data download (which can take some time). I wasn't aware of any bugs as such though I've only used the realtime quote feeds for testing purposes on one or two symbols. Given that the code base is open source, there shouldn't be any reason not to make any fixes. I might take a fix. Do they have an issue tracker? I couldn't find one.