ISMFIX Engine is configured using an XML file. The structure of the content is symetric with the deployment model of the engine.
Before working through the configuration file, we'll briefly introduce the deployment model of an engine.
Then we'll introduce the structure of the configuration file and finally, we'll work through the paramters in the file.
ISMFIX Engine's deployment model
The functional view
The Engine manages data flow between the Business Enterprise hosting the engine and the Business Client sharing data with the Enterprise.
This data flow is defined as a FIX Session by the FIX Protocol. Within the abstractions offered by ISMFIX Engine, this data flow is
a Connection. The Connection is a FIX Session with a life cycle of forever. The Connection manages the many
physical connections that may occur throughout the day with the Client.
The software design view
The configuration file is symetric with this design view. The Engine is a root component in a tree of components managed by the engine. The children of the engine are Sessions. The children of a Session are Connections. A Connection is a leaf in the tree.
The threading model is represented by the Session. All Sessions run in parallel, independent of each other from both a threading perspective and a
shared resources perspective, e.g. internal object caches. (Ignoring the obvious regarding logging which should be off during production.)
Using your performance cost function, you would define the number of Sessions available within the Engine, the set of Connections to assign to
single Engine, then workout the definition of Connections subsets that will be assigned to each Session.
This planning process is the task of statically load balancing the engine. This task is not discussed further since it requires many other variables to consider, e.g., the stability of a Client's connection, the Client's message load throughout the day and during news events, etc.
Each Session uses four threads: a connector to establish a Connection's socket, a reader to read a Connection's socket, a client handler to
process a Connection's received messages and a scheduler to schedule and process jobs outside of the client handler thread. In the configuration file, you will see the configuaration parameters for the Engine, each Session, and each connection that will be instantiated when the engine is started.
The Configuration File
In this section, we present the XML file that is an engine's configuration file that brings everything
together for an actual deployment specification.
The Configuration File Structure
The engine's configuration module that reads the XML configuration file has three features that drive how the configuration file is structured:
XML files can be included in other XML files (inherent in all XML parsers).
A command line arg of "-myCmdLineKey myCmdLineValue" is added to the XML file as
<myCmdLineKey> myCmdLineValue </myCmdLineKey>
If runtime macro expansion is a concern,
files with macros can be fully instantiated then placed under version control and
tested. Macros simply make crafting the file easier.
Macros with command lines provide an added dimension to deciding
how to craft the configs. In the example we show an example
where the command line argument is "cmdline_schedule" with values of either "WEEKDAY" or "HOLIDAY". This command line argument is then
used as part of a macro name to form the nested value lookup of a connection start time, e.g., ${${cmdline_schedule}_startTime}.
A macro value is a token that is expands to a value. The concept of a macro is synonymous with that of the environment variable where
the environment variable reaches into an environment context for the environment variable expansion, the macro reaches into the
XML file at or above the macro's location.
The configuration files are located in ISMFIX/ism_fixclient/src/test/resources/ism/fix/engine/example/configs/.
The structure of the file is one of thousands that could be used, but was chosen for it's simplicity and
self indexing of the parameters. The configuration file consists of the following:
At runtime, each command line argument will be added to the file as an element.
Include files that contain elements that will be loaded into the Engine's configuration through the use of macros.
ChannelOptions.xml - for a channel, think physical connection.
SessionOptions.xml - parameters used by all Connections within the Session.
SocketOptions.xml - socket options.
FixRepositories.xml - the available FIX Repositories available for the engine to load and used by a Connection.
TestFixConnections.xml - a partial Connection definition that will be deployed in a Session.
By having a partial Connection in a "connection-include" file, it is very easy to share the partial-connection configuration for testing
to instantiate both an Acceptor and an Initiator definition where each would have their own top level XML configuration file.
The top level configuration file for an Engine. This file includes the files above, and has the Engine's complete definition.
Configuration Files
The Engine's configuration file
We work through a top-down presentation of the Engine's configuration. It's easier to start with showing the abstract values you
want, e.g., channel options, and work down through the macros to see what they expand into.
In the the example project, there are two example engine configurations in ISMFIX/ism_fixclient/src/test/resources/ism/fix/engine/example/configs:
FixEngine_Buy_8383_8282.xml and FixEngine_Sell_8383_8282.xml (a buy side and sell side engine).
As we work through the details, we'll see that only the Session level details differ between these two.
The Session's configuration spec
The Connection's configuration spec
Details of the Include Files
See the client project's configuration files in : ISMFIX/ism_fixclient/src/test/resources/ism/fix/engine/example/configs/