Thanks for the input. Agree, multiple interface implementation is the only sensible option. It means though that I have to factor out the connect(), disconnect() methods into a further interface. The connect(), disconnect() are common to both market data providers and brokerage providers. So, I'm looking at something like: IProvider IMarketDataProvider IBroker IXXXXProvider Looking at Rightedge reminded me that I should also probably think about historical data "providers" e.g. IHistoricalDataProvider The reason I was reluctant to go this route was due to the fact that for each "provider" interface, there will need to be a separate set of callback/handler interfaces e.g. IProvider matches with IProviderHandler (methods such as onError(), onConnect(), onDisconnect()) IMarketDataProvider matches with IMarketDataHandler (methods such as onQuote(), onTrade()) etc. I'll try and put this all in UML for easier comprehension and see what people think.
Yes, that is the only logical conclusion. I'm leaning towards propogating these events via onError(), onConnect(), onDisconnect() methods on a handler interface as per previous post. The different implementations of the interfaces can then do as they see fit.
Yes, that is a possibility though it may be difficult to get the right level of granularity. I'm tempted to just throw newunsupportedmethod exception or something. It also brings up the topic of tooling/plugin support for each of the "provider" adapters. (If anyone has a better name suggestion let me know) Should the adapter have other interrogation methods? If so, what should they be? e.g. getProviderName() getAdapterVersion() getAdapterVendor() I guess some of these are static methods and part of the base "provider" interface. UML in progress...
At the weekend I went off on a major tangent when I was considering the question of "normalization" and whether Mojo should be FIX based as I believe QuantDeveloper is. As such, I spent some time getting up to speed on FIX, something I didn't really want to do in the first place. As I already knew from previous encounters, it's a bit of a mountain to climb. However, I'm still giving some serious thought to whether FIX should be at least minimally considered in the framework as it is so widely supported e.g. Velocity http://www.velocityfutures.com/Fix_platform.html via TT FIX etc. I haven't come to a final decision on how to approach this. Ideally, I'd like to support the absolute minimal amount of FIX that would be neccesary for simple ATS. If there are any FIX experts around, your input would be appreciated. FIX has the concept of session messages and application messages. The simpler application messages that would be of interest are: New Order Single Order Cancel Request Order Cancel Replace Request each of which results in an: Execution Report Despite the very large amount of tags that are available to be used in each message, only a very small amount of tags are actually required. For the trade messages they are mainly: Header Block of tags. Instrument Block of tags. Order Quantity Block of tags. Trailer Block of tags. This is where it gets vaguely interesting. The instrument block of tags includes tags such as: Symbol, Security Type, Contract Multiplier, Strike Price, Maturity Date etc. i.e. it is not too dissimilar to the Contract object in IB TWS. I believe QuantDeveloper has an Instrument Server and the notion of an Instrument that seems to be based around this Instrument block of FIX tags. It would seem feasible therefore to use the FIX instrument tags as a normalized representation of an Instrument within Mojo and pass that around leaving it to the adapters to translate into their native instrument format. I need to do a lot more research on this matter. Again, if there are any FIX experts out there also with experience of IB TWS, any insight you can offer is much appreciated.
More research bits and pieces: Mulling over the tick/bar data storage question that was posed on another thread. 1) Compressed Files. 2) Database. I was looking at two possible database solutions that might be useful: Apache Derby http://db.apache.org/derby/ Oracle Berkeley DB (formerly Sleepycat) http://www.oracle.com/technology/products/berkeley-db/index.html Berkeley DB seems particulary interesting. It doesn't support SQL or much in the way of ad-hoc querying, but this allegedly increases it's performance markedly. Instead it has put() and get() methods in lieu of INSERT and SELECT. It could almost be viewed as one big hashtable. Indeed, it has a Java Collections interface layer that can allow the database to be used just like a standard collection. I'm thinking this database could be particularly well suited to storing time series information but the tradeoff is that it doesn't have JDBC, SQL support etc. is the tradeoff worth it? It also has a 100% Java version which is nice. Anyone with knowledge on these products or any other products in conjunction with time series data storage, please feel free to add your input here!
Antonio, Are you still pimpin' your over-priced software ... But you're not a paying ET advertiser. Are you... -kt
For those of you wondering why with respect to having handler interfaces and handler implementations. Here is a brief overview of where I'm going with this. I apologize if I'm belaboring the obvious but I want to be as transparent and thorough as possible. Say your IB adapter receives a trade. The adapter will then call the onTrade() method of the handler implementation it was given. Depending on the users requirements, the handler implementation could be as simple as simply writing the information to a log file. However, for those with more ambitious requirements, the handler will do something more sophisticated. More specifically, my intention is to be able to multi-cast that trade event to all interested parties. Using a subject/observer or event/listener model obviously allows for loose coupling: you can add/remove listeners/observers dynamically without having to change the code of the subject. In summary, the handler is simply re-broadcasting the event it receives from the adapter. This is fine for simpler ATS. I have implemented a simple event/listener model for this purpose. Alternatively, one could use a more generic framework e.g. the very cool: http://java.schst.net/EventDispatcher THERE IS A PROBLEM Actually a few problems but the main one is to do with poorly behaved listeners. If you have a listener that takes a long time to do it's stuff then it blocks other listeners that are due to be notified after it i.e. there is a potential bottleneck issue. My question is: how to get around this issue? More specifically, how do you get around it in your favorite programming language/plaform? It is because of this very issue, that when developing Mojo, I will be utilizing JMS. Events can be published to a topic and subscribers can receive those events asynchronously in separate threads (provided a separate JMS session is used), separate JVMs or even separate physical machines. So, in short, JMS solves the blocking problem but also offers scalability and resilience benefits to boot. Comments/thoughts on this matter please?
Thanks, you just have! Appreciate the input. I'll use your documentation as a base to consider architectural decisions when developing Mojo in areas of overlap. Very generous of you.
I'm simply supporting consumer advocacy. I am also a business person, but one who does not implement greed into his business models. I believe in markup that is attractive to the average consumer... The Henry Ford business model, if you will. Sell it at a modest profit so that will be available to the masses. You will be just as profitable either way.
Ktmexc20 and Valdis you guys obviously have some history. I would respectfully ask you to restrain yourselves here as far as that history goes but please add your input on the topic of the thread. Okay, final words on the matter; I do not want the thread to deteriorate before it even begins. My exact words are on this thread. My reference to "shamelessly stealing ideas or even API concepts from other products" has not yet actually happened! To be sure, it's not surprising that most products take very similar approaches, after all it's just data in -> process -> place order. How different can they really be? I haven't copied anything from your documentation but once again, thank you for the link. For what it's worth, my communications with RightEdge led me to believe they were not actually familiar with your product up until recently but that is of no consequence to this thread. If you feel you are being copied, you can take it as a huge compliment. You were there first. You have first mover advantage. To re-iterate an earlier post, I give myself about 5% chance of success with this project. I will also be moving very slowly. If there is even the slightest element of thinking that this might somehow be a threat to your product, I can virtually guarantee you (95%) that it wont! Just wait till you see my crappy code.