QWFIX SDK is all about simplicity. The whole system has a sleek design so that only the features useful to developers are exposed.
In QWFIX system, the graphic based configuration tool FIX Enterprise Manager is also part of the development tool. All the configuration is done in the Enterprise Manager tool. With the QWFIX SDK, it only takes developers a couple of lines of code to load the configuration from the repository server during run time.
In FIX Enterprise Manager, we can use the graphic tool to configure the FIXEngine and FIXSession. We already knew that a QWFIX enabled application should only have one FIXEngine in a running process. A FIXEngine may contain one or more FIXSessions.
In fact, a "FIX Engine" in FIX Enterprise Manager is represented as FIXEngineSettings class in QWFIX SDK.
Similarly, a "FIX Session" in FIX Enterprise Manager is represented as FIXSessionSettings class in QWFIX SDK.
Each FIXSessionSettings is
associated with a FIXSchema. A FIXSchema
(also called FIX dictionary) represents the definition of fields and messages of
the underlying FIX session. FIX schema can be edited with the
FIX Enterprise Manager
tool to create the FIX dialect for your company.
Note: In FIX 5.0, one FIX session may communicate more than one FIX
schemas with FIXXT session protocol. FIX 5.0 is fully supported in QWFIX API and
FIX Enterprise Manager.
In QWFIX, a FIXEngine is usually associated with a standalone process. One FIXEngine can manage more than one FIXSession, so that one QWFIX enabled application can use multiple FIX sessions.
In QWFIX system, the FIXEngine and FIXSession contain not only the settings, but also operations and properties and events that can be used in run time. We will discuss more about the FIXEngine and FIXSession in later chapters.
In the new FIX transport protocol introduced since FIX 5.0, a FIX session can support more than one FIX schemas (FIX versions). See FIXSession.getDefaultSchema() and FIXSession.getSchemas() for more details.
In QWFIX, scheduler is a definition of reoccuring events. Each FIXEngine or FIXSession is associated with a scheduler. The configuration can be done with FIX Enterprise Manager GUI tool. The FIXEngine and FIXSession may have different schedulers. Also FIXEngine may contain more than one FIXSession, and each FIXSession may have a different scheduler, too.
For example, a FIXEngine may have a scheduler that keep the engine up and running for a week. The engine may manage several intraday session. So each FIXSession defined in the engine may have a daily scheduler. The engine may be started on every Monday. The engine scheduler will keep the engine up and running for a week, while the scheduler for each FIXSession will start each session in the morning and stop them in the evening, every day.
In above example, a FIXEngine may be up and running for several days while each FIXSession in the engine may be an intraday session. In QWFIX system, we introduce FIXSessionPersistence to represent the FIX message communication of each introday session. Each instance of FIXSessionPersistence is a FIX message log of one intraday FIX session.
In the example above, because a FIXEngine may be running for more than one day, there are more than one instance of FIXSessionPersistence in each FIXSession.
FIXSession keeps a list of intraday message persistences, FIXSession.getPersistences(). FIXEngine also keep a global persistence list for persistences for all FIX sessions it is managing, FIXEngine.getSessionPersistences(). In FIXSessionPersistence, there are two properties, FIXSessionPersistence.getSessionPersistenceID() and FIXSessionPersistence.getEnginePersistenceID(), that represent the index of the persistence in those lists.
Managing multiple intraday session across multiple days will result in multiple FIXSessionPersistence per FIXSession. QWFIX tries to keep the minimum overhead for each instance of FIXSessionPersistence. QWFIX doesn't unload FIXSessionPersistence. Instead, it depends on the smart FIX message cache and message compression technology. If the application developer feels that the overhead of maintaining multiple day messages is too high, he/she should use a single day scheduler on the FIX engine. So we leave it as a business decision for developers to make.
Session persistences are automatically created by scheduler during run-time. Once a new session persistence is added to the FIX engine, FIXEngineListener.sessionPersistenceAdded() event on the FIX engine will be triggered.
If the application is only used for intra-day trading, the scheduler should be set up as a daily scheduler. The process will restart every day. And there will be only one session persistence per session.
Usually multiple persistence per session only happens on sessions with "24 hour session reset" enabled.
QWFIX supports multiple FIX engines in one process. One example is our GUI based management tool, QWFIX RTAnalyzer. The RTAnalyzer can synchronize FIX communications from multiple processes, analyze the messages and present them using graphical user interface.
In order to support multiple engines, FIXEngine keeps a global list of all available FIX engines, FIX sessions and session persistences. See FIXEngine.getGlobalEngines(), FIXEngine.getGlobalSessions() and FIXEngine.getGlobalSessionPersistences() for more details (also FIXEngine.getGlobalEngineID(), FIXSession.getGlobalSessionID() and FIXSessionPersistence.getGlobalPersistenceID()).
Usually application developers only need to deal with one-FIX-engine-per-process scenario. We will talk about it in details in standalone application framework.