To further simplify the development, QWFIX introduces the application framework.
Application framework provides several classes to help developer automatically control the life cycle of FIX engines and sessions.
Different kind of application has different use cases. In the mean time, they also share some features. In QWFIX application framework, we defined the fllowing applications:
FIXStandaloneApplication is the most commonly used application. A FIXStandaloneApplication manages only one FIX engine.
Once the FIXStandaloneApplication is started, the scheduler of the engine is started, too. The scheduler will automatically start and stop the FIX engine on schedule. In turn, the FIX engine will automatically start and stop the underlying FIX sessions following each scheduler of each individual session.
when FIX engine scheduler is expired, FIXStandaloneApplication will get event notification from event handler (FIXStandaloneApplicationListener.engineStopped()). Usually the process amy choose to terminate itself upon receiving the notification. Note it's always up to application developer. FIXStandaloneApplication does not automatically terminate itself
For example, if the scheduler of the FIX engine is a daily scheduler between 7:00 AM to 7:00 PM, the process that uses FIXStandaloneApplication should start before 7:00 AM every day. Once started, the process will keep running until 7:00 PM, at which time it may choose to automatically terminate itself.
FIXStandaloneApplication is easy to use and versatile enough to cover the use cases of most of the application scenarios.
FIXRemoteReplicatorApplication is a little bit more complicated than the FIXStandaloneApplication. FIXRemoteReplicatorApplication connects to mutiple FIXStandaloneApplication enabled application processes remotely through TCP network and synchronizes the FIX message communication of selected FIX sessions (or all sessions, of course) in real time.
How is FIXRemoteReplicatorApplication able to do it? Because every FIXStandaloneApplication has the remote management feature built in. It can be enabled and disabled with Enterprise Manager management tool. As long as the remote management is enabled, the developers don't have to anything else. They don't even have to know GUI programming at all. They can just concentrate on the implementation of business logic and let QWFIX frameworks to handle the rest.
FIXRemoteReplicatorApplication can host most than one FIX engines within one process. It manages FIX engines in a slightly different way than FIXStandaloneApplication. It is used in our GUI based management tool QWFIX RTAnalyzer. It also has a lot real world applications. It basically collects FIX communications from multiple processes. With todays 64 bit multi-core hardware with hundreds of gigabyte of memory, a big trading firm is able to synchronize the entire intraday FIX communication into one single machine (actually a machine like that can host intraday trades of the entire market). As we will show in the following chapters, with our QWFIX Order Management components, orders can be recontructed from the FIX messages. So we basically have a collection of intraday orders that we can run through with a simple "for-loop". Operations like real-time order management, reporting and risk management will be made easier than ever with QWFIX system.
FIXHistoricalApplication is used to "replay" historical FIX message communications from the FIX persistent log files. FIXHistoricalApplication is the simplest application framework. It only defines 3 method calls. As long as your FIX log files are kept intact, you trading activity is safe with us and can be retrieved on demand later on at any time at extremely high speed (millions of messages per minute). There will be no information loss what so ever because every FIX tag is kept and can be inspected at any time.