In my discussion in the other thread, I mentioned that I am modeling my trading system after an operating system. I view market activity (ticks, level-2 quotes, etc) as asynchronous events that are analogous to hardware interrupts that an operating system processes. The trading engine will service and hold onto the data immediately, but then schedule strategies later for the processing of information. This design requires a formalization of the interface for the strategy scheduler.
The first strategy I have decided to implement is Don's Openings strategy. This strategy is unique in that it only works during a certain portion of the day. Because Don's Openings will be in a separate process, it will register itself to the trading engine every morning, but then remove itself from the scheduler's process list.
Rather than maintain a registry of sorts for the various strategies, the strategies themselves will use COM functionality and find a COM server in order to register themselves. Don's Openings will be a process that is scheduled to run every morning before the market opens and will receive an interface from the COM server. Strategies that are only valid during a certain portion of the day will then remove themselves as needed.
Explanation:
Don's Openings, for example, may only remain resident while it is managing a position. Once it liquidates all positions, it has to remove itself and cease to waste resources in the trading engine. There's no way for the trading engine to know when Don's Openings has to be removed, so the strategy has to inform the trading engine that it is done with managing a position and remove itself.
The COM server must now implement a formalized interface for adding and remove strategies.
ITradingEngine:
- RegisterStrategy
- UnregisterStrategy
- HeartBeat
Register strategy will also make requests for what data it is subscribing to, as well as the frequency of invocation for that data.
UnregisterStrategy should be called only when no more positions are managed; however, in the event of a critical failure, UnregisterStrategy may need a variable to turn over positions to the trading engine.
The positions that are orphaned by a failed strategy will need to be cleaned up. We can close all of them, or optionally defer them to human intervention. For the short-term, we will not worry about orphaned positions, except to say that there will be options in the design to account for them.
There is another situation in which orphaned positions can be created: whenever a heartbeat isn't received in a reasonable amount of time.
I have not fully designed the interface for order management. I am still thinking about how to design an order management interface. For example, if I separate the order management from the trading/order-routing engine, then how should the trading engine notify order management of orphaned positions?
I will be thinking about these issues over the next few days, while I rapidly crank out a prototype trading system in E-Signal and then retrofirt that strategy to work with my trading engine.
The first strategy I have decided to implement is Don's Openings strategy. This strategy is unique in that it only works during a certain portion of the day. Because Don's Openings will be in a separate process, it will register itself to the trading engine every morning, but then remove itself from the scheduler's process list.
Rather than maintain a registry of sorts for the various strategies, the strategies themselves will use COM functionality and find a COM server in order to register themselves. Don's Openings will be a process that is scheduled to run every morning before the market opens and will receive an interface from the COM server. Strategies that are only valid during a certain portion of the day will then remove themselves as needed.
Explanation:
Don's Openings, for example, may only remain resident while it is managing a position. Once it liquidates all positions, it has to remove itself and cease to waste resources in the trading engine. There's no way for the trading engine to know when Don's Openings has to be removed, so the strategy has to inform the trading engine that it is done with managing a position and remove itself.
The COM server must now implement a formalized interface for adding and remove strategies.
ITradingEngine:
- RegisterStrategy
- UnregisterStrategy
- HeartBeat
Register strategy will also make requests for what data it is subscribing to, as well as the frequency of invocation for that data.
UnregisterStrategy should be called only when no more positions are managed; however, in the event of a critical failure, UnregisterStrategy may need a variable to turn over positions to the trading engine.
The positions that are orphaned by a failed strategy will need to be cleaned up. We can close all of them, or optionally defer them to human intervention. For the short-term, we will not worry about orphaned positions, except to say that there will be options in the design to account for them.
There is another situation in which orphaned positions can be created: whenever a heartbeat isn't received in a reasonable amount of time.
I have not fully designed the interface for order management. I am still thinking about how to design an order management interface. For example, if I separate the order management from the trading/order-routing engine, then how should the trading engine notify order management of orphaned positions?
I will be thinking about these issues over the next few days, while I rapidly crank out a prototype trading system in E-Signal and then retrofirt that strategy to work with my trading engine.
